Scrum Standards

These are the team's codified practices. The agent enforces all of these when generating and validating Scrum artifacts.

Project Intake Questionnaire

Before generating any Scrum artifacts, the agent runs a structured discovery phase — asking the user questions one at a time in a conversational flow. This is the "flipped prompt" technique: the agent gathers what it needs before it acts.

Questionnaire Flow

The agent asks these questions sequentially. Each question is asked individually, the user responds, and the agent moves to the next. The agent adapts follow-up questions based on previous answers.

Phase 1 — Project Context

Phase 2 — Team & Capacity

Phase 3 — Technical Context

Phase 3a — Codebase Context

Phase 4 — Risks & Unknowns

Phase 5 — Preferences & Process

Phase 6 — Capacity Planning

After Q28 (bank holidays), the agent asks about planned leave (PTO):

• Per-person entry with name, start date, and end date (DD/MM/YYYY format with validation)
• Dates outside the planning window are rejected
• Working-day calculation excludes weekends
• Summary shown after each entry with option to add more
• Quick mode skips PTO (defaults to 0)

Adaptive Behavior

The questionnaire is not rigid — the agent adapts:

• Skips questions the user already answered. If your initial description included "we're a team of 4 using React and Node", the agent won't re-ask team size or tech stack.
• Extracts answers from descriptions. Keyword matching detects project type (greenfield/existing), integrations (Stripe, Auth0), and infrastructure constraints (Kubernetes, microservices).
• Uses conditional essentials. Q7 (team roles) only appears if Q6 (team size) was answered. Q12 (integrations) only if Q11 (tech stack) was answered.
• Asks targeted follow-ups. Instead of generic "tell me more", the agent uses question-specific probing templates.
• Validates across questions. Catches contradictions — e.g., team size of 1 but multiple roles listed.
• Adapts question text. "You said 5 engineers — what are their roles?" instead of static text.
• Allows "skip" and "I don't know". Proceeds with reasonable defaults and flags assumptions.
• Summarizes before proceeding. After all questions, presents a structured summary for confirmation.

Intake Summary Output

After the questionnaire, the agent produces a structured summary:

Here's what I understand about your project:

  Project:        E-commerce platform redesign
  Type:           Existing codebase (monolith → microservices migration)
  End Users:      Online shoppers, internal warehouse staff
  Target State:   Fully migrated to microservices with new checkout flow

  Team:           5 engineers (2 backend, 2 frontend, 1 devops)
  Sprint Length:  2 weeks
  Velocity:       25 pts/sprint (default: 5 × 5 engineers, no historical data)
  Target Sprints: 6 sprints (12 weeks)

  Tech Stack:     Python/FastAPI, React, PostgreSQL, AWS ECS
  Integrations:   Stripe (payments), SendGrid (email), existing REST API
  Constraints:    Must maintain backward compat with mobile app v2.x

  Risks:
    - Payment flow migration (high complexity, Stripe webhook changes)
    - No clear spec for warehouse dashboard requirements

  Out of Scope:   Mobile app redesign, analytics pipeline

  Output:         Jira + Markdown export

  Does this look right? [Confirm / Edit]

Only after the user confirms does the agent proceed to feature generation.

Issue Hierarchy

User Stories

Format

User stories follow this structure:

"As a [persona], I want to [goal], so that [benefit]."

Breaking It Down

Examples

• As Max, I want to invite my friends, so we can enjoy this service together.
• As Sascha, I want to organise my work, so I can feel more in control.
• As a manager, I want to understand my colleagues' progress, so I can better report our successes and failures.

Story Point Rules

Velocity Calculation Examples:

Auto-Split Example:

If the agent estimates "Build the full payment integration" at 13 points:

This story exceeds the 8-point maximum. Splitting:

  Original: Build the full payment integration (13 pts)

  Split into:
    US-010: Set up Stripe SDK and payment intent flow    (5 pts)
    US-011: Build webhook handler for payment events      (5 pts)
    US-012: Add payment error handling and retry logic    (3 pts)

  Total: 13 pts across 3 stories (all ≤ 8)

  [Accept split / Edit / Reject]?

Discipline Tagging

Every story is tagged with the primary discipline needed:

Story Checklist

Before a story is considered ready for sprint planning, it must have:

• Clear persona identified
• Goal is implementation-free and user-focused
• Benefit ties to real business or user value
• Acceptance criteria written (see Acceptance Criteria)
• Story points estimated (1–8 range)
• Dependencies identified and linked
• Fits within a single sprint

Acceptance Criteria

What They Are

Acceptance criteria are clear, concise, and testable statements that define the conditions a user story must meet to be accepted by stakeholders and considered "Done." They are the source of truth for developers, testers, and product stakeholders.

Purpose

• Clarify the scope of a user story
• Ensure shared understanding between product, platform, and stakeholders
• Provide a basis for test cases
• Define the boundaries of success

Acceptance criteria describe what should happen, not how it's implemented. They avoid technical specifics and focus on the desired outcome.

Key Characteristics

Format: Given / When / Then

All acceptance criteria use the Given / When / Then format:

Given [precondition]
When  [action]
Then  [expected outcome]

Examples

Reset Password

User Story: As a user, I want to reset my password so that I can regain access to my account.

Given I am on the password reset page
When  I enter my registered email and click "Send Reset Link"
Then  I should see a confirmation message saying "Reset link sent to your email"

Form Validation

User Story: As a user, I want to be informed when I submit an invalid phone number.

Given I enter an invalid phone number
When  I try to submit the form
Then  I should see an error message saying "Please enter a valid phone number"

Negative / Edge Case

User Story: As a user, I want to be prevented from registering with an already-used email.

Given I am on the registration page
When  I enter an email that is already registered and click "Sign Up"
Then  I should see an error message saying "An account with this email already exists"
And   no duplicate account should be created

Coverage Requirements

Every story must have acceptance criteria covering:

Common Pitfalls

Definition of Done — User Story

A story is not "Done" until every applicable item is satisfied. The agent evaluates which DoD items apply to each story and marks the rest as N/A.

Acceptance Criteria Fully Met

• Acceptance criteria are written before work begins
• Reviewed and approved by the team during backlog refinement
• All criteria are fully met and tested
• Given/When/Then format used consistently

Documentation

• Relevant documentation created or updated
• Added to the appropriate shared space / folder
• Outdated documentation updated if affected by the change
• Documentation completed within the sprint (unless explicitly agreed otherwise)

Testing

• Testing conducted across all environments where changes are deployed
• Test cases clearly identified and documented
• End-to-end (E2E) tests included for business-critical services where applicable
• Testing deemed sufficient before marking as Done

Code Merged

• Branch merged into main / master via Pull Request
• PR reviewed by at least two engineers
• All review comments and questions fully addressed before merge

Released via SDLC

• Release conducted through the standard SDLC process (e.g., Jenkins pipeline)
• Release channel notified with relevant details (e.g., #developer-releases on Slack)
• Story not marked Done until successfully released

Stakeholder Sign-Off (if required)

• Sign-off received from relevant stakeholders for features impacting external teams
• Approval logged (Slack message, Jira comment, or verbal approval noted in ticket)

Knowledge Sharing

• If the change introduces new functionality, architectural decisions, or process changes — a knowledge-sharing activity is conducted
• This can be a Slack update, team demo, short write-up, or Confluence page
• Ensures team-wide understanding and reduces knowledge silos

Definition of Done — Spike

Spikes are time-boxed research tasks used to reduce uncertainty, explore solutions, or gain clarity before delivery work begins.

When to Use a Spike

• Investigating an unknown technical or product area
• Evaluating possible solutions or approaches
• Identifying potential blockers or risks
• Prototyping or validating ideas before full implementation

Checklist

The goal of a spike is learning and knowledge sharing — not production-ready code.

Sprint Ceremonies

Backlog Health

Priority Levels

Backlog Hygiene Rules

• Stories older than 3 sprints without movement should be reviewed — re-prioritise or remove
• Every story in the backlog must have a clear persona, goal, and benefit
• Stories without acceptance criteria are not ready for sprint planning
• Blocked stories must have the blocker documented and linked

Story Splitting Guidelines

When a story is too large (estimated above 8 points), split it using one of these strategies:

The goal is to produce stories that are each independently valuable, testable, and completable within a sprint.