⌘K
Proposal Demo
Planning & Execution

CTO Demo Scenario

1. Demo Objective

The demonstration must show that TeamFlow controls requirement changes without preventing valid business decisions.

The demo should focus on one realistic scenario and take approximately 10 to 12 minutes.

2. Demo Project Context

Project Name: Regional Warehouse Management

Project Code: RWM

Scenario: Expanding warehouse access control to support multiple facility assignments while maintaining data security and audit compliance.

3. Demo Users

  • Aisha — Business Analyst
  • Nimal — Project Manager
  • Farhan — Technical Lead
  • Devika — Developer
  • Rizwan — QA Engineer
  • CTO Demo User — CTO
  • Management Demo User — Management

4. Initial Requirement

Requirement Number: REQ-RWM-0001

Title: Restrict regional staff to assigned warehouses

Business Objective: Ensure that regional staff can access only warehouses assigned to them.

Initial Business Rule: One regional staff member can be assigned to one warehouse.

Acceptance Criterion:

Given a regional staff member is assigned to Warehouse A, when the user logs into the system, then only Warehouse A is displayed.

5. Demo Preparation

The demo reset script must:

  1. Reset the demo database to known state
  2. Create all demo users with correct roles
  3. Create the RWM project with members
  4. Create REQ-RWM-0001 in draft
  5. Create Version 1.0 and approve
  6. Add sample review history
  7. Prepare sample tasks linked to requirement
  8. Prepare sample test cases
  9. Prepare dashboard baseline

Commands:

make demo-reset
make demo-start

6. Demo Flow (10-12 minutes)

Scene 1: View Approved Requirement (2 min)

Actor: CTO Demo User

  • Log in to TeamFlow
  • Navigate to RWM project
  • Open REQ-RWM-0001
  • Show:
    • Structured requirement format
    • Business objective and workflow
    • Acceptance criteria
    • Approval history (BA ✓, PM ✓, Tech ✓, QA ✓)
    • Version 1.0 status: APPROVED
    • Linked tasks (development in progress)
    • Linked test cases

Scene 2: Business Changes Request (1 min)

Actor: Management Demo User

  • Log in as Management
  • Review REQ-RWM-0001
  • Say: "Business needs have changed. A regional manager now needs access to multiple warehouses."
  • Create a change request:
    • Requested Change: "Allow one regional staff to be assigned to multiple warehouses"
    • Business Reason: "Regional managers need flexibility for coverage during absences"
    • Urgency: HIGH

Scene 3: Impact Analysis (2 min)

Actors: Technical Lead, QA Engineer

  • Log in as Farhan (Technical Lead)
  • Review change request and add technical impact:
    • Backend effort: 8 hours (new logic for multiple assignments)
    • Database effort: 4 hours (schema change, data migration)
    • Risk: MEDIUM
  • Log in as Rizwan (QA)
  • Add QA impact:
    • New test cases: 6
    • Existing tests requiring review: 3
    • Regression scope: MEDIUM
    • QA effort: 6 hours

Scene 4: Change Approval (1 min)

Actor: CTO Demo User

  • Log in as CTO
  • Review all impact analyses
  • Say: "This is a reasonable business change with acceptable technical effort. Approved for the current release."
  • Approve change request
  • Show that system automatically:
    • Created new version 1.1 (draft)
    • Copied content from version 1.0
    • Applied the change: new business rule added
    • Linked new version to change request
    • Marked affected test cases as REVIEW_REQUIRED

Scene 5: Version Comparison (1 min)

Actor: CTO Demo User

  • Show version comparison view:
  • Version 1.0 (Approved) on left
  • Version 1.1 (Draft) on right
  • Highlight the changed business rule:
    • OLD: "One regional staff member can be assigned to one warehouse"
    • NEW: "One regional staff member can be assigned to one or more warehouses"
  • Say: "The original approved version is still here. Nothing was silently changed."

Scene 6: Review New Version (1 min)

Actor: Aisha (BA)

  • Log in as Aisha
  • Review version 1.1 (in review workflow)
  • Approve new version from BA perspective
  • Show: Change request is tracked throughout approval chain

Scene 7: Audit Trail (1 min)

Actor: CTO Demo User

  • Show audit log for REQ-RWM-0001:
  • Creation by Aisha (date/time)
  • Review history for version 1.0
  • Approval by each role
  • Change request creation by Management (date/time)
  • Impact analyses by Tech and QA
  • Approval by CTO (date/time, reason)
  • New version 1.1 creation
  • Say: "Every decision is recorded and traceable. We know exactly when the requirement changed, why, who approved it, and what the impact was."

Scene 8: Closing Summary (1 min)

Actor: CTO Demo User

  • Summarize what the demo showed:
    • ✓ Approved requirements cannot be silently changed
    • ✓ Business changes are recorded formally
    • ✓ Impact analysis is mandatory
    • ✓ New versions preserve the original
    • ✓ Complete audit trail of all decisions
    • ✓ Traceability from requirement to tasks to tests
  • Say: "TeamFlow provides the governance we need without preventing legitimate business changes."

7. Key Points to Emphasize

  • Original version 1.0 is still there, unchanged
  • No silent modifications—everything is explicit
  • Impact analysis prevents surprises
  • Multiple approvers ensure quality
  • Complete audit trail for compliance
  • Developers have a clear, stable version to implement
  • QA knows exactly what to test
  • Management sees the cost of changes

Next: Review the CTO Proposal →