Eventmodeling Brainstorming Events

Brainstorming Events

Interview Phase (Optional)

When to Interview: Skip if the user has provided detailed, well-documented requirements (written user stories, feature specs, business rules). Interview when requirements are vague, incomplete, or when domain expertise is uncertain.

Interview Strategy: Ensure requirements are complete and team understands domain well enough to brainstorm comprehensively. Identify hidden complexity areas upfront.

Critical Questions

When requirements need clarification:

1. Requirements Completeness (Impact: Determines if brainstorm is likely to be exhaustive)

• Question: "How complete are your requirements? Do you have: (A) Written user stories/specs, (B) Documented business rules, (C) Rough list, (D) Just verbal descriptions?"
• Why it matters: Incomplete requirements cause missed events; complete requirements enable comprehensive brainstorm
• Follow-up triggers: If (C) or (D) → probe for missing scenarios; if rules aren't documented → ask team to state them explicitly

2. Domain Expertise & Familiarity (Impact: Shapes who should participate and what guidance is needed)

• Question: "Who understands this domain best? (A) Product/Domain expert leading brainstorm, (B) Engineering team figuring it out, (C) Mix of roles"
• Why it matters: Domain expert participation dramatically improves event completeness; solo engineering leads to gaps
• Follow-up triggers: If (B) → recommend inviting domain expert; if (C) → ask how decisions will be made

3. Known Complexity Areas (Impact: Determines where to focus brainstorming effort and depth)

• Question: "Are there specific areas known to be complex or error-prone? (e.g., payment processing, state transitions, business rules)"
• Why it matters: Complex areas often have hidden events; identifying them upfront ensures they're covered
• Follow-up triggers: For each complex area → ask "What are the edge cases? What can go wrong?"

4. Explicit Business Rules & Constraints (Impact: Ensures no implicit assumptions; may reveal missing events)

• Question: "What are critical business rules that govern this domain? (e.g., 'orders can only be cancelled within 24 hours', 'payments must be authorized before confirmation')"
• Why it matters: Business rules often generate specific events; documenting them prevents overlooking state changes
• Follow-up triggers: For each rule → ask "When this rule is violated, what event signals that?"

Interview Flow

Conditional Entry:

If user has provided:
  - Written requirements or user stories (not just verbal)
  - AND documented business rules or constraints
  - AND named domain experts who will participate

Then: Skip interview, proceed directly to brainstorming

Else: Conduct interview

Phase 1: Requirements Assessment (Questions 1-2)

• Gauge requirements completeness
• Confirm domain expertise available
• Adjust brainstorm scope accordingly

Phase 2: Complexity Mapping (Questions 3-4)

• Identify areas needing deep exploration
• Document rules that may generate events
• Plan brainstorm focus areas

Capturing Interview Findings

Append findings to the project's event modeling file:

File: .trogonai/interviews/[project-name]/EVENTMODELING.md

Use Write tool to add/update this section:

## 2. Brainstormed Events (eventmodeling-brainstorming-events)

### Requirements Assessment
[From Q1: Written requirements? Documented rules?]

### Domain Expertise
[From Q2: Who understands domain? Available for participation?]

### Role Catalog
#### Human Roles
- [Role 1]: [Description] → Actions: [list]
- [Role 2]: [Description] → Actions: [list]
#### System Actors
- [Actor 1]: [Description] → Triggers: [list]

### Event Streams (Stream Roots)
- Stream: [Name] (Identity: [id field])
  - Events: [Event1, Event2, Event3]
  - State changes: [State transitions]

### Business Rules & Constraints
[From Q3 & Q4]
- Rule 1: [Statement] → [Events it generates]
- Rule 2: [Statement] → [Events it generates]
- Constraint 1: [Limitation]

### Brainstorming Focus Areas
- [Focus area 1]
- [Focus area 2]

Update Interview Trail:

| 2 | eventmodeling-brainstorming-events |  [today] | Event streams, business rules, constraints |

This section feeds into subsequent steps (plotting, storyboarding, etc.)

---

Workshop Facilitation Guide

Setting: This is a collaborative brainstorming workshop. The facilitator guides participants to envision the system and extract events rapidly.

The Brainstorming Flow

Phase 1: Understand Goals (5-10 min)

• Someone explains project goals
• What problem are we solving?
• Who are the users?
• What are key outcomes?

Phase 2: Free Brainstorm (15-20 min) Facilitator asks:

"What events could happen in this system? When something changes, what event occurs? Put down ANY event you think of."

Participants call out events (sticky notes or digital cards):

"Customer places order"
"Order confirmed"
"Payment received"
"Inventory updated"
"Order shipped"
"Delivery confirmed"
"Return requested"
"Refund issued"

Phase 3: Gentle Filtering (10-15 min) Facilitator introduces state-changing concept gently:

Facilitator: "Now let's think about these events. An event is something that
CHANGED THE STATE of the system. It's something important that happened that
others need to know about.

Let me ask: Does 'Customer viewed the catalog' change anything?
Participants: "Well... no, they just looked."
Facilitator: "Right, so it's not an event. But if they SELECTED an item
               from catalog, that changes what's in their cart, so that's
               a state change. Call that 'ItemAddedToCart'."

Does 'Payment received' change something?
Participants: "Yes! Order goes from confirmed to paid."
Facilitator: "Exactly! That's an event—state changed."

Key points to clarify:

• "Customer logged in" → Maybe not state-changing (unless we track logins)
• "Customer created account" → State-changing event
• "System checked inventory" → Internal action, not state-changing
• "Inventory reserved" → State-changing event
• "Email sent" → Notification, not state-changing (unless we track email history)
• "Notification requested" → Could be state-changing if we track preferences

Tips for Facilitators

Make it conversational:

• Don't say: "You identified a non-state-changing event"
• Say: "Interesting! Does that actually change anything in the system?"

Use examples from their world:

• If e-commerce: "Like if someone just browsed but didn't buy?"
• If banking: "Like if they just checked balance but didn't withdraw?"

Don't be rigid:

• If unsure whether something is state-changing, include it and refine later
• Some events seem minor now but matter in implementation
• Better to capture everything than miss important events

Capture the "why":

• Don't just list events, capture context
• Why would this event matter?
• Who cares about it? (Other systems, views, business rules)

Workflow

When given domain requirements, perform the following analysis:

1. Identify User Roles & Actors (MANDATORY)

Before brainstorming events, define who interacts with the system. Every event model needs an explicit role catalog — without it, downstream steps (storyboarding, commands, scenarios) lack clarity on who does what.

Identify all human roles and system actors:

• Human roles: Customer, Seller, Admin, Support Agent, Reviewer, etc.
• System actors: Payment Gateway, Inventory System, Notification Service, Scheduler, etc.

For each role/actor, document:

• Name: Use domain language (e.g., "Seller" not "User Type B")
• Description: What this role does in the domain (1-2 sentences)
• Key actions: What state changes can this role initiate?
• Permissions boundary: What can this role NOT do?

Present as a Role Catalog:

## Role Catalog

### Human Roles

1. **Customer** - Description: End user who browses, purchases, and tracks orders
   - Key actions: Create order, confirm order, cancel order, submit review
   - Cannot: Manage inventory, process refunds, respond to reviews as seller

2. **Seller** - Description: Merchant who lists products and fulfills orders
   - Key actions: List product, confirm stock, respond to reviews, update pricing
   - Cannot: Place orders, approve own reviews, process payments

3. **Support Agent** - Description: Internal staff handling escalations and manual overrides
   - Key actions: Override order status, issue refunds, flag reviews
   - Cannot: Place orders on behalf of customers (unless impersonating)

### System Actors

1. **Payment Gateway** (external)
   - Triggers: Payment authorization, payment failure, refund confirmation
   - Communication: Webhooks

2. **Inventory System** (internal)
   - Triggers: Reserve inventory, release reservation
   - Communication: Event-driven

This catalog feeds directly into:

• Step 3 (Storyboarding): One swimlane per human role
• Step 4 (Inputs): Every command attributed to a specific role/actor
• Step 7 (Scenarios): Scenarios reference roles by name
• Step 8 (Completeness): Verify every role has at least one command path

2. Identify Event Streams (Stream Roots)

Identify the main entities that will have event streams. These are NOT DDD aggregates—they're simply the logical roots of events:

• User/Account
• Order
• Payment
• Shipment
• etc.

For each stream root, note:

• Name (use domain language, not technical terms)
• Identity key (what uniquely identifies instances: orderId, paymentId, customerId, etc.)
• What commands will affect it (we'll define state needs per command, not upfront)

3. Identify Business Processes

Map out critical workflows:

• What steps does a user go through?
• What are the decision points?
• Where do systems integrate?

4. Extract State Changes

For each process, identify what state changes occur:

• Customer places order → Order created
• Payment processed → Order confirmed
• Item shipped → Order status changed

These become your domain events.

5. Document Business Rules & Constraints

• What rules govern state transitions?
• What validations must pass?
• What are the invariants?

Examples:

• "Order can only be shipped if payment is confirmed"
• "Inventory must be reserved before order confirmation"
• "Customer can only cancel within 24 hours"

6. Create Analysis Document

Present findings in this structure (include facilitation notes for future workshops):

## Workshop Notes

**Participants**: [List roles: PO, Dev, QA, Domain Expert]
**Duration**: [Time spent]
**Key facilitation moments**: [What helped clarify understanding?]

---

# Domain Analysis: [Domain Name]

## Role Catalog

### Human Roles
1. **[Role Name]**: [Description]
   - Key actions: [What this role can do]
   - Cannot: [Permission boundaries]

### System Actors
1. **[Actor Name]** ([internal/external]): [Description]
   - Triggers: [What events/commands it initiates]
   - Communication: [Webhooks / Event-driven / API]

## Event Streams (Stream Roots)
List each stream root and its identity:
- **Stream**: Review (Identity: reviewId)
- **Stream**: SellerResponse (Identity: responseId)
- **Stream**: Seller (Identity: sellerId)

Note: These are just the logical groupings of events. The STATE needed for each command will be determined later—not all stream attributes are needed for all commands.

## Business Processes
1. **Process Name**: Description
   - Actor: Who initiates?
   - Steps: 1. → 2. → 3.
   - Outcomes: What changes?

## Identified State Changes (Potential Events)
- [Stream] [Verb]: When? Why? (Use past tense: "ReviewPublished", "SellerResponseAdded")

## Business Rules & Constraints
- Rule 1: Condition and consequence
- Rule 2: Constraint description

## Questions for Domain Expert
- Any gaps in understanding?
- Unclear processes?

Output Format

Present analysis in a clear markdown structure that can be directly used by the eventmodeling-designing-event-models skill.

Core Architectural Rule

NEVER use DDD Aggregate pattern for state design Every command handler must have its own minimal state projection derived from events. This is non-negotiable.

 ANTI-PATTERN (Do NOT do this):
OrderAggregate { orderId, customerId, items[], total, status, paymentId, address, shippedAt, cancelledAt, ... }
Used by: ConfirmOrder, ShipOrder, CancelOrder, ApproveReturn
Problem: Loads unused data, couples unrelated commands, violates minimal state principle

 CORRECT PATTERN:
ConfirmOrderState { status, orderId }
ShipOrderState { status, orderId, paymentId }
CancelOrderState { status, orderId, createdAt }
Each command loads ONLY what it needs.

Key Principles

• Use domain language, not technical terms
• Focus on what happens, not how it's implemented
• Identify state changes as events, not actions (gently!)
• Document constraints and rules
• Be specific with examples from the requirements
• Collaborative Process: This is a group brainstorm, not a solo analysis
• Rapid Iteration: Capture quickly, refine later
• Gentle Filtering: Introduce "state-changing events" concept conversationally, not as rigid rule
• Event Sourcing Mindset: Think in terms of immutable events and stream roots, NOT DDD aggregates. The stream root is just a logical grouping of events; state is minimal and command-specific.
• Defer State Design: Don't list all entity attributes upfront. In the model designer step, we'll define minimal state projections needed for each specific command.
• Command State Isolation: Each command handler has its own state shape. Different commands = different state interfaces.

Best Practices for Requirements Analysis

1. Be Specific with Requirements

Provide concrete examples and clear scope:

• "Handle orders"
• "Orders have items, pricing, delivery address, and can be cancelled within 24 hours"

2. Use Domain Language

Use terms your business understands, not technical jargon:

• "obj1 references obj2"
• "Customer places Order with Products"

3. Document Constraints Explicitly

Make implicit rules explicit:

• "Process payments"
• "Authorize payment before marking order confirmed; refund if shipment fails"

4. Verify Role Catalog Completeness

Cross-check that the Role Catalog (from Step 1) covers all actors referenced in events and processes:

• "Orders can be created" (by whom?)
• "Customers can create orders; sellers can confirm stock; system can cancel if payment fails"

5. Cover Edge Cases

Include error and boundary conditions:

• "What happens if payment is declined?"
• "Can an order be modified after shipping starts?"
• "What triggers order cancellation?"

Quality Checklist

• [ ] Every event is past tense and names a completed state change (e.g., OrderPlaced, not PlaceOrder)
• [ ] Role Catalog lists every actor (human roles and system processors) with distinct responsibilities
• [ ] Each event can be traced back to a specific actor in the Role Catalog
• [ ] No CRUD events (UserUpdated, RecordDeleted) — events describe business moments, not database operations
• [ ] All known error and boundary conditions have corresponding events
• [ ] Events group into at least one recognizable business process flow
• [ ] No overlapping event semantics — two events don't mean the same thing

Facilitating Event Modeling Workshops

Overview

Event Modeling is fundamentally a collaborative workshop process. This guide helps facilitators run efficient, effective workshops across all 7 steps.

Pre-Workshop Preparation

1. Select Participants

Required Roles:

• Product Owner/Domain Expert: Business rules, priorities, constraints
• Developers (2-3): Technical feasibility, implementation concerns
• QA/Tester (1-2): Test coverage, edge cases
• Facilitator (1): Keeps pace, ensures shared understanding

Optional Participants:

• UX Designer: User workflows, interface considerations
• Security Lead: Sensitive data handling, compliance
• Operations: Deployment, monitoring, scaling
• Customer/User: Real-world perspective (for workshops with actual users)

Group Size: 5-8 people is ideal

• Too small: Miss perspectives
• Too large: Hard to facilitate

2. Pre-Workshop Communication

Send to participants before workshop:

Subject: Event Modeling Workshop - [Domain Name]

Hi team,

We're running an Event Modeling workshop to design the [Domain] system.

Date: [Date]
Duration: [Hours]
Location: [Physical/Virtual]

Please prepare by thinking about:
  - What workflows happen in this system?
  - What events could occur?
  - What's important about state changes?
  - Questions you have about requirements

No prior Event Modeling experience needed!

Looking forward to seeing you there.

3. Prepare Workspace

Physical Workshop:

Setup:
  - Large whiteboard or wall space (8+ feet wide)
  - Sticky notes (multiple colors for events, commands, views)
  - Markers (bold colors)
  - Timer visible
  - Cameras for documentation

Layout:
  - Stand-up around board
  - Facilitator at board
  - Everyone can see and contribute

Virtual Workshop:

Tools:
  - Miro, Figma, or similar
  - Video conference (Zoom, Teams, etc.)
  - Shared document (for notes)

Setup:
  - Everyone can see canvas
  - All can create/edit
  - Recording enabled (for reference)
  - Chat open for side discussions

4. Create Templates

Prepare sticky note templates or digital shapes:

Physical sticky notes:
[Green] Event: ________________

[Blue] Command: ________________

[Orange] View: ________________

Virtual shapes:
Same colors with text fields

Workshop Facilitation by Step

Step 1: Brainstorming Events (15-20 minutes)

Objective: Identify all domain events (state changes)

Facilitation Flow:

1. Set Context (2 min)

   "We're going to envision what this system does. Imagine it's running
   for years—what events happen? What important state changes?

   An event is something that changed the state. Not just something
   that happened, but something that MATTERS because it changed things.

   Everyone write down any events you think of."

2. Free Brainstorm (8-10 min)

• Participants call out events
• You write on board or digital canvas
• No filtering yet! Capture everything
• Encourage "What about..." questions
• Example responses:
• "Customer placed order" → Write: "OrderCreated"
• "Order was confirmed" → Write: "OrderConfirmed"
• "What about customer viewed page?" → "Let's capture it for now, we'll refine"

3. Gentle Filtering (5-7 min)

   "Now let's think about these. An event is something that actually
   changed the state. Let me ask about some:

   'Customer viewed catalog' - did this change anything?
   Person: Not really...
   You: Right, viewing doesn't change anything. But if they SELECTED
        an item, that changes their cart. That's 'ItemAddedToCart'.

   'System checked inventory' - did this change system state?
   Person: No, it's internal...
   You: Exactly, internal checks don't count. But when we ACTUALLY
        reserved inventory, that's a state change: 'InventoryReserved'.

4. Capture Insights - Add notes on WHY events matter

• Identify stream roots (Order, Payment, Review, etc.)
• Document any questions for domain expert

Timing Guide:

• Tight groups: 12-15 min
• Complex domains: 20-25 min
• Always watch time—keep moving

Step 2: Plotting Events (Timeline)

Objective: Order events into a timeline (process flow)

Facilitation Flow:

1. Establish Order (5 min)

   "Let's put these events in order. What happens first?"

   Guide conversation:
   "Before we can confirm an order, what must happen?"
   → "Order must be created first"

   "So the sequence is?"
   → Lead to: OrderCreated → OrderConfirmed

2. Handle Branches (5 min)

   "Can different things happen from here?"

   "What if payment fails?"
   → "PaymentFailed event"
   → This creates branching paths

   Draw branching clearly:
   OrderConfirmed
     → PaymentAuthorized → (success path)
     → PaymentFailed → (failure path)

3. Identify Parallel Flows (5 min)

   "Do these happen at the same time or one after another?"

   Example:
   "Once payment is authorized, what happens?"
   → "Inventory reserved"
   → "Email sent"
   → Can these happen in parallel? Usually yes!

Don't get stuck on exact timing—the point is the logical flow.

Step 3: Storyboarding (UI Mockups)

Objective: Visualize what users see

Facilitation Flow:

1. Pick First Screen (2 min)

   "Let's think about the UI. What's the first screen the user sees?"
   → "Order entry form"

   "Who draws?"
   → Can be anyone, or facilitator

2. Draw and Label (5 min)

   Draw on board:
   
    Order Entry Form     
   
    Customer: [_______] 
    Items: [___] [___]  
    [Submit]             
   

   Label each field:
   Customer ← from CreateOrder command
   Items ← user selection

3. Trace Data (3 min)

   "Where does this data go?"
   → "Into the event"
   → "Then what screen shows next?"
   → Draw: Confirmation screen with same data

4. Identify Missing (2 min)

   "Can we see everything we need on this screen?"
   → If missing: "We'll need to add that to the event"
   → Add to list of clarifications

Time per screen: 5-7 minutes (don't perfect, iterate)

Step 4: Identifying Inputs (Commands)

Objective: Map user actions to commands

Facilitation Flow:

1. Extract from Storyboards (5 min)

   "Looking at the screens, what are users doing?"
   → "Clicking Submit" → "CreateOrder command"
   → "Selecting payment" → "ConfirmOrder command"

   Write commands clearly

2. Identify Processor Inputs (5 min)

   "What does the system do automatically?"
   → "Check payment gateway" → "AuthorizePayment command"
   → "Reserve inventory" → "ReserveInventory command"

   Mark these as [ Automation]

3. Specify Data (5 min)

   "For each command, what data does it need?"

   CreateOrder needs:
     - customerId (from form/session)
     - items (from form selection)
     - shippingAddress (from form)

   Write this clearly

4. Validation Questions (5 min)

   "What validation must pass?"

   CreateOrder:
     - Customer must exist
     - Items must not be empty
     - Address must be complete

   Write these as business rules

Step 5: Identifying Outputs (Events & Views)

Objective: Specify events and read models

Facilitation Flow:

1. Events from Commands (5 min)

   "For each command, what event happens?"

   CreateOrder → OrderCreated (what fields?)
   Specify exactly what fields:
     - orderId (generated)
     - customerId (from command)
     - items (from command)
     - total (calculated)

2. Read Models (5 min)

   "What views do users need?"
   → "Order status view"
   → "Order list view"
   → "Order detail view"

   "What data in each?"
   → Status view: All order details
   → List view: Summary only

3. Event → View Mapping (5 min)

   "OrderCreated → Status View shows:"
   - orderId
   - items
   - total
   - status=Draft

   "OrderConfirmed → Status View updates:"
   - status=Confirmed
   - confirmedAt timestamp

Step 6: Apply Conway's Law (System Boundaries)

Objective: Identify systems and responsibilities

Facilitation Flow:

1. Ask the Question (2 min)

   "Who does what?"

   "Is payment something WE do or does an external system?"
   → If external: PaymentGateway system

2. Draw Boundaries (5 min)

   Visually separate:

   Our System:
      Order service
      Inventory service
      Notification service

   External:
      Payment gateway
      Fulfillment provider

3. Clarify Ownership (5 min)

   "Which system owns each event?"

   OrderCreated → Our Order system
   PaymentAuthorized → Payment system (external) or our bridge?
   InventoryReserved → Our Inventory system

4. Identify Team Structure (5 min)

   "Who builds what?"

   → Team A: Order service
   → Team B: Payment processor
   → Team C: Inventory management

   Boundaries = team boundaries (Conway's Law)

Step 7: Elaborating Scenarios (Given-When-Then)

Objective: Specify behavior with Gherkin format

Facilitation Flow:

1. Happy Path First (8 min)

   "Let's write the success case. What's the normal flow?"

   Scenario: Create order successfully
     Given: Customer exists, products exist
     When: Customer creates order with items
     Then: OrderCreated event produced, status=Draft

   Write on board/doc with team reviewing

2. Failure Cases (8 min)

   "What can go wrong?"

   Scenario: Reject with invalid customer
     Given: Customer ID doesn't exist
     When: CreateOrder attempted
     Then: Command rejected, no event

   → Quick, obvious failures
   → Don't overthink

3. State Validation (5 min)

   "What if the order is in wrong state?"

   Scenario: Can't confirm already-confirmed order
     Given: Order already in Confirmed state
     When: Confirm attempted again
     Then: Rejected

4. Alternative Paths (5 min)

   "Any different ways this could work?"

   Scenario: Can't confirm order with no payment method
   Scenario: Can retry if payment fails

   Capture alternatives quickly

Time: 5-7 min per command/view, don't perfect

Facilitation Techniques

Handling Different Personalities

Quiet developers:

• Direct question: "Alex, what do you think about this?"
• Don't embarrass, just engage
• "Good point, add that"

Dominating voices:

• Politely redirect: "Thanks, let me get input from others"
• "Interesting, let's capture that and check with the team"
• Keep energy high so they feel heard

Skeptics:

• Take seriously: "What's your concern?"
• Don't dismiss: "That's valid, let's think about it"
• Sometimes reveal real issues

Idea-generators:

• Capture everything: "Good ideas, adding them"
• Sort later: Don't slow momentum
• "We'll come back to that"

Keeping Energy & Pace

Good pacing:
  - 5-7 min per item (not 20 min perfecting one detail)
  - Move quickly between steps
  - Regular breaks (every 45-60 min)
  - Stand, don't sit (keeps energy up)

Warning signs of bad pacing:
  - People checking phones
  - Someone talking endlessly
  - "Um... let me think..." (too hard)
  - Fatigue setting in

Recovery:
  - Take 10-min break
  - Change activity (switch from drawing to writing)
  - Refocus on goals: "We're 60% done, here's what we still need"

Dealing with Disagreement

Situation: Two people disagree on event

Option A: "Both are valid? Can we combine?"
Option B: "Let's see if later steps clarify?"
Option C: "Let's note both and revisit"

Don't: Get stuck on one issue
Do: Keep moving, document decision

Decision-making:
  1. If there's a clear right answer → Use it
  2. If reasonable people disagree → Document both, move on
  3. If it doesn't matter now → Defer to implementation team

Remote Workshop Adaptations

Virtual vs. Physical

Advantages of virtual:

• Can record (perfect reference)
• Can save digital artifacts
• Easier for distributed teams
• Can use video recordings in onboarding

Challenges:

• Less natural interaction
• Harder to facilitate drawing
• Zoom fatigue
• Side conversations harder

Adaptations:

1. Shorter sessions (90 min instead of 4 hours)
2. More breaks (10 min every 30 min)
3. Structured input (everyone adds ideas before discussing)
4. Clearer roles (one person drawing, one taking notes)
5. Recording on (for those who can't attend live)
6. Async follow-up (give people time to digest)

Post-Workshop

Immediate (Same Day)

1. Capture on Document - Photograph/screenshot all artifacts

• Type up handwritten notes
• Create digital version of diagram

2. Share with Team - Everyone gets copy

• Add notes: "Why did we choose this?"
• Link to recordings

3. Identify Gaps - Note unclear items

• Schedule quick follow-up if needed

Follow-Up (1-2 Days)

1. Distribute Summary - What we covered

• Key decisions
• Outstanding questions

2. Request Feedback - Any clarifications needed?

• Anything we missed?
• Concerns?

3. Next Steps - Next workshop scheduled?

• Who's doing design/implementation?
• When do we start?

Multi-Day Workshop Schedule

For large or complex projects:

Day 1 (Steps 1-3): 4 hours
  - 9am-10am: Brainstorming events (Step 1)
  - 10am-11am: Plotting timeline (Step 2)
  - Break: 11am-11:15am
  - 11:15am-1pm: Storyboarding (Step 3)
  - Lunch: 1pm-2pm

Day 2 (Steps 4-7): 4 hours
  - 9am-10am: Identifying inputs (Step 4)
  - 10am-11am: Identifying outputs (Step 5)
  - Break: 11am-11:15am
  - 11:15am-12:30pm: System boundaries (Step 6)
  - 12:30pm-1pm: Scenario planning (Step 7 intro)
  - Lunch/break

Day 3 (Scenarios & Polish): 3 hours
  - 9am-12pm: Elaborate scenarios (Step 7, detailed)
  - Document findings
  - Plan next steps

Facilitation Checklist

Before Workshop

• [ ] Invitations sent 1 week prior
• [ ] Right people confirmed attending
• [ ] Room/tech tested
• [ ] Materials prepared (sticky notes, markers, templates)
• [ ] Facilitator briefing done
• [ ] Objectives clear to all

During Workshop

• [ ] Started on time
• [ ] Explained purpose and format
• [ ] Each step has clear objective
• [ ] Captured everything (photo/digital)
• [ ] Timing maintained (didn't get stuck)
• [ ] Everyone participated
• [ ] Energy and engagement stayed high
• [ ] Decisions documented
• [ ] Ended on time

After Workshop

• [ ] Artifacts digitized and shared
• [ ] Summary created
• [ ] Gaps identified
• [ ] Feedback requested
• [ ] Next steps scheduled
• [ ] Team has clear deliverables

Success Indicators

Good workshop:

• Everyone participated
• Decisions were made and documented
• Artifacts created and shared
• Team understands the model
• Clear next steps
• Energy was good throughout

Needs improvement:

• Some people quiet the whole time
• Unclear what we decided
• No clear artifacts
• "Are we building this in Java or Python?" (forgotten basics)
• People left tired/frustrated