Agile & Scrum with Waymaker Taskboards

Last Updated: October 10, 2025 Difficulty: Intermediate Estimated Reading Time: 20 minutes

Overview

Agile methodology has revolutionized software development and project management by emphasizing iterative delivery, team collaboration, and rapid response to change. Waymaker taskboards provide a powerful platform for implementing agile practices, with native support for sprints, epics, user stories, and velocity tracking. Whether you're running Scrum, Kanban, or a hybrid approach, Waymaker gives you the flexibility and structure to succeed.

This comprehensive guide covers everything you need to implement agile and Scrum methodologies in Waymaker, from initial board setup through sprint execution, ceremonies, and continuous improvement. You'll learn how to structure your board, manage your backlog, plan sprints, track velocity, and run effective agile ceremonies that keep your team aligned and productive.

What You'll Learn

• Core principles of agile methodology and how they apply to Waymaker
• Complete Scrum framework implementation (sprints, roles, ceremonies)
• Sprint planning process from backlog grooming to commitment
• User story creation with acceptance criteria and estimation
• Backlog management and prioritization strategies
• Daily standup workflows using taskboards
• Sprint review and demo preparation
• Retrospective facilitation and action tracking
• Velocity tracking and forecasting techniques
• Scaling agile across multiple teams
• Common agile anti-patterns and how to avoid them

Prerequisites

• Understanding of agile methodology fundamentals
• Familiarity with Waymaker taskboards (see Interface Overview)
• Knowledge of creating layers (see Creating and Managing Layers)
• Understanding of Epic and Sprint layer types (see Layer Types Explained)

Agile Principles and Values

Before diving into implementation, let's review the core principles that make agile effective.

The Agile Manifesto

Core Values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

How Waymaker Supports These Values:

• Individuals and interactions: Real-time collaboration, comments, @mentions
• Working software: Focus on deliverable user stories, not documentation
• Customer collaboration: Guest access for customer involvement
• Responding to change: Easy backlog re-prioritization, flexible sprint planning

Twelve Agile Principles

1. Satisfy customers through early and continuous delivery
2. Welcome changing requirements, even late in development
3. Deliver working software frequently (weeks, not months)
4. Business and developers work together daily
5. Build projects around motivated individuals
6. Face-to-face conversation is most effective
7. Working software is primary measure of progress
8. Sustainable development at constant pace
9. Continuous attention to technical excellence
10. Simplicity - maximize work not done
11. Self-organizing teams produce best results
12. Regular reflection and adjustment

Agile in Waymaker

Waymaker taskboards embody these principles through:

• Iterative sprints: Regular delivery cycles
• Visual boards: Transparent progress for all stakeholders
• Flexible prioritization: Easy backlog management
• Team collaboration: Real-time updates and communication
• Continuous improvement: Retrospective tracking and action items

The Scrum Framework

Scrum is the most popular agile framework, providing structure through defined roles, events, and artifacts.

Scrum Roles

Product Owner:

• Defines product vision and roadmap
• Manages and prioritizes product backlog
• Accepts or rejects completed work
• Represents stakeholder interests
• Makes final decisions on scope

In Waymaker: Typically has full board access, manages backlog layer, sets task priorities

Scrum Master:

• Facilitates Scrum ceremonies
• Removes impediments for team
• Coaches team on agile practices
• Protects team from interruptions
• Ensures Scrum process followed

In Waymaker: Manages sprint layers, facilitates board updates, monitors progress

Development Team:

• Self-organizing and cross-functional
• Estimates and commits to work
• Delivers working increments
• Collaborates daily
• Typically 3-9 members

In Waymaker: Team members assigned to tasks, update status daily, collaborate via comments

Scrum Events (Ceremonies)

Sprint:

• Time-boxed iteration (1-4 weeks, typically 2)
• Fixed duration throughout project
• Produces potentially shippable increment
• Cannot be extended or shortened mid-sprint

Sprint Planning:

• Duration: 2-4 hours for 2-week sprint
• Team selects work from backlog
• Creates sprint goal
• Commits to sprint backlog
• Outcome: Sprint ready to start

Daily Standup:

• Duration: 15 minutes, same time daily
• Each member answers: What did I do? What will I do? Any blockers?
• Not a status meeting - focus on collaboration
• Scrum Master facilitates

Sprint Review:

• Duration: 1-2 hours for 2-week sprint
• Demo completed work to stakeholders
• Gather feedback
• Update product backlog based on learning
• Outcome: Validated increment

Sprint Retrospective:

• Duration: 1-1.5 hours for 2-week sprint
• Team only (no stakeholders)
• Discuss: What went well? What didn't? What to improve?
• Create action items for next sprint
• Outcome: Continuous improvement

Backlog Refinement:

• Duration: 1-2 hours weekly
• Not official Scrum event but highly recommended
• Groom upcoming stories
• Estimate and add details
• Keep backlog ready for planning

Scrum Artifacts

Product Backlog:

• Ordered list of everything needed in product
• Single source of requirements
• Continuously refined and prioritized
• Product Owner owns and manages
• Never complete (evolves with product)

In Waymaker: Create as "Product Backlog" custom layer containing unscheduled user stories

Sprint Backlog:

• User stories committed for current sprint
• Team owns and manages
• Updated daily
• Visible to all stakeholders
• Represents sprint commitment

In Waymaker: Stories assigned to current sprint layer, tracked across Kanban sections

Product Increment:

• Sum of all completed work
• Must be "Done" per Definition of Done
• Potentially shippable
• Cumulative across sprints

In Waymaker: Completed tasks marked as done, meeting acceptance criteria

Setting Up Your Agile Board

A well-structured board is the foundation of effective agile practice in Waymaker.

Recommended Board Structure

Two-Level Hierarchy:

Level 1: Epics (major features or themes)
Level 2: Sprints (time-boxed iterations)
Tasks: User Stories (deliverable work items)

Alternative: Sprint-Focused Structure:

Level 1: Sprints (time-boxed iterations)
Tasks: User Stories (organized by sprint)
Separate Layer: Product Backlog (unscheduled stories)

Step-by-Step Board Creation

Step 1: Create Your Board

1. Navigate to Taskboards
2. Click "Create Taskboard"
3. Name: "[Product Name] Development" or "Agile Board - [Team Name]"
4. Type: Project
5. Description: Product vision and team information
6. Create board

Step 2: Configure Workflow Sections

Customize sections for agile workflow:

Recommended Sections:

• Backlog: Unrefined or unscheduled stories
• Ready: Stories refined and ready for sprint
• To Do: Sprint stories not yet started
• In Progress: Stories actively being worked
• Review/QA: Stories in code review or testing
• Done: Completed stories meeting Definition of Done

To Configure:

1. Board Settings → Sections
2. Add/rename sections as above
3. Set "Done" as completion status
4. Save changes

Step 3: Define Your Epics

Identify major feature areas or themes:

1. Open Layer Manager
2. Add Layer → Type: Epic
3. Name: "User Authentication" (or your feature)
4. Description: Epic scope, business value, success criteria
5. Dates: Estimated epic timeline (flexible)
6. Color: Purple (#8B5CF6) - consistent for all epics
7. Create layer

Repeat for each major epic (typically 3-8 active epics)

Step 4: Create Product Backlog Layer

1. Add Layer → Type: Custom
2. Name: "Product Backlog"
3. Description: "User stories not yet assigned to a sprint"
4. Color: Gray (#6B7280)
5. Create layer

Step 5: Create Your First Sprint

1. Select parent epic in Layer Manager
2. Add Sub-layer → Type: Sprint
3. Name: "Sprint 1: Oct 14-27" (number and dates)
4. Description: Sprint goal and team capacity
5. Dates: Exact start and end (critical)
6. Color: Blue (#3B82F6) - consistent for all sprints
7. Create layer

Your agile board is ready!

Creating and Managing Epics

Epics organize related user stories around major features or business capabilities.

What Makes a Good Epic?

Size: Too large for single sprint (3-8 sprints typical)

Value: Delivers meaningful business or user value

Theme: Cohesive feature set or capability

Decomposable: Breaks into user stories

Measurable: Success criteria defined

Epic Creation Process

Step 1: Identify Epic Opportunities

Sources:

• Product roadmap initiatives
• Customer feature requests (grouped)
• Technical infrastructure needs
• Market opportunities
• Platform expansion

Step 2: Write Epic Description

## Epic: Advanced Reporting Dashboard

### Business Value
Enable customers to analyze their data through customizable reports
and visualizations, supporting our goal of increasing user engagement
by 30% and reducing churn by 15%.

### User Impact
Users can:
- Create custom reports with drag-and-drop interface
- Visualize data with 10+ chart types
- Schedule automated report delivery
- Share reports with team members
- Export reports in multiple formats (PDF, Excel, CSV)

### Scope
Included:
- Report builder interface
- Chart library (bar, line, pie, scatter, heat map, etc.)
- Scheduled report automation
- Report sharing and permissions
- Export functionality

Excluded (future epics):
- Real-time dashboard updates
- Advanced analytics (regression, forecasting)
- Custom data source connectors

### Success Criteria
- 60% of active users create at least one report within 30 days
- Report creation time under 5 minutes for standard reports
- User satisfaction rating > 4.5/5 for reporting features
- < 1% support tickets related to reporting

### Estimated Effort
5 sprints (10 weeks), approximately 200 story points

### Dependencies
- Data warehouse schema finalized
- API endpoints for data access
- Chart library evaluated and selected

Step 3: Create Epic Layer

1. Layer Manager → Add Layer
2. Type: Epic
3. Name: "Advanced Reporting Dashboard"
4. Description: Paste epic description above
5. Dates: Oct 14 - Dec 22 (estimated epic duration)
6. Color: Purple
7. Create

Step 4: Decompose into User Stories

Break epic into deliverable user stories:

• As a user, I can create a new blank report
• As a user, I can select data sources for my report
• As a user, I can add filters to refine report data
• As a user, I can create a bar chart visualization
• As a user, I can create a line chart visualization
• As a user, I can save my report
• As a user, I can schedule automated report delivery
• As a user, I can share reports with team members

Create these as tasks in Product Backlog initially, move to sprints during planning.

Epic Sizing Guidelines

Small Epic (1-3 sprints, 50-100 points):

• Single feature addition
• Example: "Password Reset Functionality"

Medium Epic (3-5 sprints, 100-200 points):

• Complete feature set
• Example: "User Profile Management"

Large Epic (5-8 sprints, 200-400 points):

• Major capability
• Example: "Advanced Reporting Dashboard"

Too Large (8+ sprints, 400+ points):

• Consider splitting into multiple epics
• Example: Split "Complete CRM System" into "Contact Management", "Deal Pipeline", "Email Integration"

Sprint Planning and Management

Sprint planning transforms your product backlog into committed work for the upcoming iteration.

Pre-Planning Preparation

1-2 Days Before Planning:

Product Owner:

• Review and prioritize backlog
• Ensure top 20 stories are refined
• Prepare sprint goal candidates
• Review team capacity

Team:

• Review refined stories
• Research technical approaches
• Identify questions for Product Owner
• Review past sprint velocity

Scrum Master:

• Schedule planning meeting (block calendar)
• Prepare velocity data
• Set up board filters
• Gather any planning materials

Sprint Planning Meeting

Duration: 4 hours for 2-week sprint (2 hours per week of sprint)

Attendees: Full Scrum team (Product Owner, Scrum Master, Dev Team)

Part 1: What Will We Deliver? (2 hours)

1. Review Sprint Goal Candidates

   • Product Owner presents goal options
   • Team discusses and selects primary goal
   • Goal should be achievable in one sprint

2. Calculate Team Capacity

   Team Capacity = (Team Members) × (Working Days) × (Focus Factor)
   
   Example:
   - Team: 6 developers
   - Sprint: 10 working days
   - Focus Factor: 70% (accounts for meetings, interruptions)
   - Time off: 2 team members out 1 day each
   - Capacity: (6 × 10 × 0.7) - 2 = 40 story points
   

3. Select User Stories

   • Start with highest priority stories
   • Pull stories that support sprint goal
   • Stop when capacity reached
   • Don't overcommit

In Waymaker:

1. Filter board to "Product Backlog" layer
2. Sort by priority
3. For each selected story:
   • Open task editor
   • Change Layer from "Product Backlog" to "Sprint [N]"
   • Change Section to "To Do"
   • Save

Part 2: How Will We Do It? (2 hours)

1. Break Down Stories

   • Discuss implementation approach
   • Identify tasks within stories
   • Estimate effort
   • Identify dependencies

2. Identify Risks

   • Technical unknowns
   • External dependencies
   • Resource constraints
   • Potential blockers

3. Final Commitment

   • "Can we complete this work?"
   • Team consensus required
   • Adjust scope if needed
   • Document commitment

Update Sprint Layer:

## Sprint 5: Oct 14-27

### Sprint Goal
Implement core reporting functionality including report builder interface,
data source selection, and basic chart creation.

### Team Capacity
- Team size: 6 developers
- Sprint length: 10 working days
- Time off: Sarah (Oct 20), Mike (Oct 21)
- Velocity target: 40 story points
- Committed: 38 story points

### Committed Stories
1. Report builder UI (5 pts)
2. Data source selection (3 pts)
3. Filter creation (5 pts)
4. Bar chart visualization (8 pts)
5. Line chart visualization (8 pts)
6. Save report functionality (5 pts)
7. Report permissions (4 pts)

### Risks
- Chart library integration (new dependency)
- Data API performance for large datasets
- Mitigation: Spike chart library integration on Day 1

### Definition of Done
- Code complete and merged
- Unit test coverage > 80%
- Code review passed
- QA testing complete
- Documentation updated

User Story Creation and Estimation

User stories are the atomic units of work in agile, describing features from the user's perspective.

User Story Format

Template: As a [role], I can [capability], so that [benefit]

Components:

• Role: Who is this for? (user, admin, customer, etc.)
• Capability: What can they do?
• Benefit: Why do they want to do it?

Examples:

Good User Stories:

• ✅ "As a user, I can reset my forgotten password so that I can regain access to my account"
• ✅ "As an admin, I can view login history so that I can monitor for suspicious activity"
• ✅ "As a customer, I can filter products by price so that I can find options within my budget"

Poor User Stories:

• ❌ "Password reset" (not in user story format)
• ❌ "As a user, I want the system to be fast" (not specific, not testable)
• ❌ "Update the login page" (not from user perspective)

INVEST Criteria

Good user stories are INVEST:

Independent: Can be completed without depending on other stories Negotiable: Details can be discussed and refined Valuable: Delivers value to user or business Estimable: Team can estimate effort Small: Fits in one sprint Testable: Clear acceptance criteria exist

Creating User Stories in Waymaker

Step 1: Create the Task

1. Navigate to board
2. Click "+" in Backlog section
3. Enter user story title
4. Task modal opens

Step 2: Complete Story Details

Title: User story in standard format

Description:

## User Story
As a user, I can create a bar chart from my report data so that
I can visualize trends and comparisons.

## Acceptance Criteria
- [ ] User can select "Bar Chart" from chart type dropdown
- [ ] User can choose X-axis dimension (category)
- [ ] User can choose Y-axis measure (numeric value)
- [ ] Chart renders with correct data
- [ ] Chart is responsive (adapts to screen size)
- [ ] User can customize chart colors
- [ ] Chart includes axis labels and title
- [ ] Chart displays correctly with 1-1000 data points

## Technical Notes
- Use Chart.js or D3.js library
- Lazy load chart library (not on initial page load)
- Cache chart data for 5 minutes
- Support accessibility (keyboard navigation, screen readers)

## Design
[Link to Figma mockup]

## Testing Strategy
- Unit tests: Chart data transformation
- Component tests: Chart rendering
- E2E test: Complete chart creation flow
- Visual regression test: Chart appearance

Layer: "Product Backlog" (or sprint if already planned)

Estimate: Story points (see estimation section below)

Priority: High/Medium/Low

Tags: "frontend", "reporting", "visualization"

Assignee: (Leave blank until sprint, or assign during planning)

Step 3: Save Task

Acceptance Criteria Best Practices

Acceptance criteria define "done" for the story.

Format Options:

Checklist (Recommended):

## Acceptance Criteria
- [ ] User can click "Create Report" button
- [ ] Report wizard opens with step 1: Data Source
- [ ] User can select from available data sources
- [ ] User can proceed to step 2: Configuration
- [ ] User can navigate back to previous steps
- [ ] User can save draft report
- [ ] User can complete and view final report

Gherkin/BDD Format:

## Acceptance Criteria

**Scenario: Create New Report**
Given I am on the reports page
When I click "Create Report"
Then I see the report wizard
And I can select a data source

**Scenario: Save Report Draft**
Given I am creating a report
When I click "Save Draft"
Then my report is saved
And I can return to it later

Given-When-Then Format:

## Acceptance Criteria
- Given I have selected a data source
  When I choose "Bar Chart"
  Then I see the bar chart configuration options

- Given I have configured my chart
  When I click "Generate"
  Then I see the rendered chart

Tips:

• Make criteria specific and testable
• Include edge cases and error scenarios
• Cover both happy path and failure cases
• Ensure QA can test without additional context

Story Point Estimation

Story points measure relative effort, complexity, and uncertainty.

Story Point Scale

Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21

Why Fibonacci? It reflects increasing uncertainty at larger sizes.

Modified Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

Some teams add fractional points (0.5) and round numbers for larger estimates.

What Story Points Represent

Not Hours: Story points are relative, not time-based

Effort: How much work is required? Complexity: How difficult is the task? Uncertainty: How well do we understand requirements?

Example:

• Effort: Adding a form field is low effort
• Complexity: Integrating OAuth is high complexity
• Uncertainty: New technology has high uncertainty

Estimation Guidelines

1 point: Trivial

• Fix typo in UI
• Update color constant
• Add simple validation
• ~1 hour work

2 points: Simple

• Add form field with validation
• Create basic API endpoint
• Write unit tests for function
• ~2-3 hours work

3 points: Standard

• Implement CRUD for simple entity
• Create new UI component
• Add authentication to endpoint
• ~4-6 hours work

5 points: Moderate

• Implement login flow
• Create complex form
• Integrate third-party API
• ~1 day work

8 points: Complex

• OAuth integration
• Advanced search with filters
• Real-time collaboration feature
• ~2-3 days work

13 points: Very Complex

• Complete authentication system
• Payment processing integration
• Reporting dashboard
• ~3-5 days work

21+ points: Too Large

• Entire user management system
• Should be split into smaller stories
• Epic-sized work

Estimation Techniques

Planning Poker:

1. Moderator reads story aloud
2. Team discusses acceptance criteria and scope
3. Each member selects estimate privately (using cards or digital tool)
4. Reveal simultaneously (prevents anchoring)
5. Discuss differences - especially outliers (highest and lowest explain reasoning)
6. Re-estimate until consensus reached
7. Record estimate in task

Benefits:

• Whole team involvement
• Surfaces different perspectives
• Quick consensus building
• Fun and engaging

Relative Sizing:

1. Select reference stories (small, medium, large)
2. Compare new story to references
3. "This is similar to Story X, which was 5 points"
4. Estimate based on similarity

Benefits:

• Fast estimation
• Leverages team knowledge
• Consistent over time

T-Shirt Sizing (Then Convert):

1. Estimate as XS, S, M, L, XL
2. Convert to points: XS=1, S=2, M=5, L=8, XL=13

Benefits:

• Easy for new teams
• Less intimidating than numbers
• Quick gut-feel estimation

Setting Estimates in Waymaker

1. Open task editor
2. Find "Estimate (points)" field
3. Enter story point value
4. Save task

When to Estimate:

• During backlog refinement (recommended)
• During sprint planning
• Not when creating story initially (insufficient information)

Backlog Management and Grooming

A well-maintained backlog is essential for successful sprint planning.

Product Backlog Structure

Organization:

Product Backlog (Layer)
├── Ready for Sprint (High Priority)
│   ├── Stories with full details
│   ├── Acceptance criteria defined
│   ├── Estimated (story points)
│   └── Technical approach discussed
│
├── Near-Term (Medium Priority)
│   ├── Stories for next 2-3 sprints
│   ├── Basic details
│   └── Rough estimates
│
└── Future/Icebox (Low Priority)
    ├── Ideas and requests
    ├── Minimal details
    └── No estimates yet

Backlog Refinement (Grooming)

Frequency: Weekly or bi-weekly

Duration: 1-2 hours

Attendees: Product Owner + 2-4 rotating team members

Goals:

• Refine upcoming stories
• Add estimates
• Add acceptance criteria
• Break down large stories
• Re-prioritize as needed

Refinement Process:

Week 1: Focus on Sprint N+1

1. Review top 15-20 stories
2. Product Owner explains each story
3. Team asks clarifying questions
4. Add acceptance criteria
5. Estimate story points
6. Identify dependencies
7. Mark stories as "Ready for Sprint"

Week 2: Focus on Sprint N+2

1. Review next 15-20 stories
2. Initial estimates
3. Identify research needs
4. Break down epics into stories

In Waymaker:

1. Filter to "Product Backlog" layer

2. Sort by priority

3. For each story being refined:

   • Open task
   • Add/update description with acceptance criteria
   • Add estimate
   • Add tags (frontend, backend, design, etc.)
   • Update priority if needed
   • Save

4. Use comments to capture discussion points

5. @mention team members for follow-up

Definition of Ready

A story is "Ready for Sprint" when:

• Written in user story format
• Acceptance criteria defined and clear
• Estimated (story points assigned)
• Small enough for one sprint (typically ≤ 13 points)
• Dependencies identified
• Design mockups available (if UI work)
• Technical approach discussed
• Testable (team knows how to verify)
• Priority assigned

In Waymaker: Add "ready-for-sprint" tag or move to "Ready" section

Backlog Prioritization

Prioritization Factors:

1. Business Value: Revenue impact, strategic importance
2. User Value: User satisfaction, feature requests
3. Risk Reduction: Technical unknowns, dependencies
4. Dependencies: Prerequisite for other work
5. Effort: Cost to implement

Prioritization Techniques:

MoSCoW Method:

• Must Have: Critical, non-negotiable
• Should Have: Important but not critical
• Could Have: Nice to have
• Won't Have: Out of scope for now

WSJF (Weighted Shortest Job First):

WSJF = (Business Value + Time Criticality + Risk Reduction) / Effort

Higher score = Higher priority

Value vs Effort Matrix:

High Value, Low Effort → Do First
High Value, High Effort → Plan Carefully
Low Value, Low Effort → Fill Sprint Capacity
Low Value, High Effort → Avoid/Defer

In Waymaker:

1. Set task Priority: High/Medium/Low
2. Use List view to drag and reorder
3. Top of backlog = next sprint candidates
4. Review priority weekly

Sprint Execution and Daily Standups

Once sprint planning is complete, execution begins.

Sprint Kickoff

Day 1 of Sprint:

1. Team aligns on sprint goal
2. Review sprint backlog
3. Team members self-assign first stories
4. Identify any immediate blockers
5. Set daily standup time (if not already established)

In Waymaker:

• Team members assign themselves to tasks
• Move first tasks to "In Progress"
• Add comments with implementation notes

Daily Standup

Schedule: Same time every day (typically 9-10 AM)

Duration: 15 minutes maximum

Format: Each team member answers three questions

Three Questions:

1. What did I complete yesterday?

   • Focus on completed work
   • Reference specific tasks

2. What will I work on today?

   • State commitment
   • Mention task names

3. Do I have any blockers?

   • Impediments preventing progress
   • Needs from other team members
   • External dependencies

Example:

"Yesterday I completed the bar chart component (Task #234).
Today I'll work on the line chart component (Task #235).
I'm blocked on the data API - Mike, can we pair on that after standup?"

Using Waymaker in Standup:

Option 1: Kanban Board View

1. Display board on shared screen
2. Filter to current sprint layer
3. Each person references their tasks
4. Update task status live during standup

Option 2: List View

1. Filter to current sprint + assigned to each person
2. Quick review of each person's tasks
3. Update status and assignments

After Standup:

• Scrum Master works to remove blockers
• Team members pair up for collaboration
• Tasks moved to appropriate sections

Work in Progress (WIP) Limits

WIP Limits Prevent:

• Context switching
• Unfinished work piling up
• Bottlenecks in workflow
• Lack of focus

Recommended Limits:

• 1-2 tasks per developer in "In Progress"
• Finish current work before starting new
• Team agrees on limits together

In Waymaker:

• Monitor "In Progress" section
• Encourage moving tasks to "Review" or "Done" before pulling new work
• Use comments to indicate WIP limit reached

Managing Sprint Changes

Scope Changes During Sprint:

General Rule: Avoid changing sprint scope

Exception Cases:

• Critical production bug
• Regulatory requirement
• Customer emergency

Process:

1. Product Owner evaluates urgency
2. Team assesses impact
3. If must add work, remove equivalent work from sprint
4. Document change in sprint description
5. Communicate to stakeholders

In Waymaker:

• Add urgent task to sprint layer
• Remove equivalent story (move back to backlog)
• Add comment explaining scope change
• Update sprint description with change log

Sprint Review and Demo

Sprint review demonstrates completed work to stakeholders and gathers feedback.

Sprint Review Meeting

Timing: Last day of sprint or first day after sprint ends

Duration: 1-2 hours for 2-week sprint

Attendees: Scrum team + stakeholders (customers, executives, other teams)

Goals:

• Demonstrate working increment
• Gather feedback
• Update product backlog
• Foster collaboration

Review Agenda

1. Sprint Overview (5 minutes)

• Review sprint goal
• Highlight what was completed
• Mention what wasn't completed (if any)

2. Demo Completed Work (45-60 minutes)

• Show each completed user story
• Demonstrate in realistic scenarios
• Focus on user value, not technical details
• Encourage questions and feedback

3. Stakeholder Feedback (20-30 minutes)

• What worked well?
• What could be improved?
• New ideas or requirements?
• Priority changes?

4. Product Backlog Update (10-15 minutes)

• Add new stories from feedback
• Adjust priorities based on learning
• Update roadmap if needed

Preparing for Sprint Review

2-3 Days Before:

• Ensure all "Done" stories meet Definition of Done
• Prepare demo environment
• Create demo script/story flow
• Identify who will demo each story

Day Of:

• Test demo environment
• Prepare fallback (screenshots, video) if live demo risky
• Set up room/screen sharing for remote attendees

In Waymaker:

Demo Preparation:

1. Filter to current sprint layer
2. Filter to "Done" section
3. Review each completed story
4. Check all acceptance criteria met
5. Note any that don't meet DoD (discuss with PO)

Demo Flow:

• Show stories in logical order (user journey, not random)
• Reference task descriptions for context
• Check off acceptance criteria during demo

Accepting or Rejecting Work

Product Owner Evaluates:

• Does it meet acceptance criteria?
• Is it production-quality?
• Does it align with requirements?

Outcomes:

Accepted:

• Story marked complete
• Congratulate team
• Move on to next story

Conditionally Accepted:

• Minor issues don't block completion
• Create follow-up stories for improvements
• Mark story complete

Rejected:

• Doesn't meet acceptance criteria
• Move back to "In Progress" or backlog
• Add comments with required changes
• May pull into next sprint

In Waymaker:

• Accepted: Keep in "Done", mark complete
• Rejected: Move to "To Do" or back to backlog
• Add comment with feedback

Sprint Retrospective

Retrospective is where the team reflects and commits to improvement.

Retrospective Meeting

Timing: After sprint review, before next sprint planning

Duration: 1-1.5 hours for 2-week sprint

Attendees: Scrum team only (no stakeholders, no managers unless team agrees)

Safe Space: Team must feel comfortable sharing honest feedback

Retrospective Format

Classic: What Went Well / What Didn't / What to Improve

1. Set the Stage (5 minutes)

• Review retrospective purpose
• Remind of safe space
• State working agreements (be honest, be kind, focus on improvement)

2. Gather Data (20 minutes)

• Each person adds sticky notes:
  • Green: What went well
  • Red: What didn't go well
  • Blue: Questions or puzzles

3. Generate Insights (20 minutes)

• Group similar items
• Discuss themes
• Vote on top 3-5 items to discuss

4. Decide What to Do (20 minutes)

• For each top item, brainstorm improvements
• Select 1-3 concrete actions for next sprint
• Assign owners to action items
• Make actions specific and measurable

5. Close Retrospective (5 minutes)

• Summarize action items
• Appreciate team's honesty
• Confirm next retrospective date

Alternative Formats:

Start/Stop/Continue:

• Start: What should we start doing?
• Stop: What should we stop doing?
• Continue: What should we keep doing?

4 Ls:

• Loved: What did we love?
• Learned: What did we learn?
• Lacked: What was missing?
• Longed For: What do we wish we had?

Sailboat:

• Wind: What's helping us move forward?
• Anchor: What's holding us back?
• Rocks: What risks do we see?
• Island: What's our goal?

Documenting Retrospective in Waymaker

Update Sprint Layer Description:

## Sprint 5: Oct 14-27 - Retrospective

### Date
October 27, 2025

### What Went Well ✅
- Bar chart integration smoother than expected
- Great collaboration between Sarah and Mike on data API
- Effective use of pair programming for complex stories
- All code reviews completed within 24 hours
- Team met sprint goal!

### What Didn't Go Well ❌
- Data API performance issues caused delays (2 days)
- Report permissions story was underestimated (should have been 8 pts, not 4)
- Design mockups for line chart arrived on Day 3 (should have been before sprint)
- Too many context switches from production bugs

### Insights 💡
- Need earlier design involvement (before sprint planning)
- Should add technical spike for performance testing
- Estimation improving but still optimistic on some stories
- Production bug interruptions affecting flow

### Action Items for Sprint 6
- [ ] Request designs 1 week before sprint planning (Owner: PO)
- [ ] Add 0.5 day spike for API performance testing (Owner: Mike)
- [ ] Review and update estimation for authentication-related stories (Owner: Team)
- [ ] Implement "bug duty" rotation to reduce context switching (Owner: Scrum Master)
- [ ] Celebrate sprint goal achievement! (Owner: Everyone 🎉)

### Metrics
- Velocity: 38 points (target: 40)
- Stories completed: 7 of 8 (87.5%)
- Sprint goal: Achieved ✅
- Team happiness: 8/10

### Notes
Team morale high despite some challenges. Good problem-solving and
collaboration. Ready for next sprint!

Create Action Items as Tasks:

1. Create task for each action item
2. Assign to owner
3. Add to next sprint
4. Track completion

In Waymaker:

• Create tasks in next sprint layer
• Tag with "retrospective-action"
• Set priority: High (actions are commitments)
• Review in next retrospective

Following Up on Action Items

Next Retrospective:

1. Review previous action items
2. Discuss: What happened? Did it help?
3. Celebrate completed actions
4. Close out or carry forward incomplete actions

Continuous Improvement:

• Track action item completion rate
• Focus on 1-3 actions per sprint (not 10)
• Make actions specific and measurable
• Ensure actions have owners

Velocity Tracking and Forecasting

Velocity is your team's capacity for delivering work, measured in story points per sprint.

Calculating Velocity

After Each Sprint:

1. Sum story points of all completed stories
2. Only count stories meeting Definition of Done
3. Record velocity for sprint
4. Calculate rolling average (last 3-5 sprints)

Example:

Sprint 1: 32 points completed
Sprint 2: 38 points completed
Sprint 3: 35 points completed
Sprint 4: 40 points completed
Sprint 5: 38 points completed

Rolling Average (last 5): (32+38+35+40+38)/5 = 36.6 points per sprint

Velocity in Waymaker

Manual Calculation:

1. Filter to sprint layer
2. Filter to "Done" section
3. Sum story points of completed tasks
4. Record in sprint description

Sprint Summary:

### Sprint 5 Metrics

**Velocity:**
- Committed: 40 points
- Completed: 38 points
- Velocity: 38 points
- Completion rate: 95%

**Historical Velocity:**
- Sprint 1: 32 pts
- Sprint 2: 38 pts
- Sprint 3: 35 pts
- Sprint 4: 40 pts
- Sprint 5: 38 pts
- Average: 36.6 pts

Using Velocity for Planning

Sprint Planning:

• Average velocity: 36.6 points
• Plan next sprint for ~37 points
• Don't overcommit to 50+ points based on hope

Release Forecasting:

Epic: Advanced Reporting Dashboard
Remaining Work: 120 story points
Average Velocity: 37 points per sprint
Estimated Sprints: 120 / 37 = 3.2 sprints
Estimated Completion: ~7 weeks from now

Roadmap Planning:

Q4 Goals: 3 epics totaling 360 points
Available Sprints: 6 sprints in Q4
Required Velocity: 360 / 6 = 60 points per sprint
Current Velocity: 37 points per sprint

Conclusion: Not enough capacity. Options:
1. Reduce scope (cut 1-2 epics)
2. Increase team size
3. Extend timeline into Q1

Velocity Best Practices

Do:

• Use velocity for planning
• Track velocity over time
• Calculate rolling average (3-5 sprints)
• Account for team changes
• Accept velocity fluctuations

Don't:

• Use velocity to compare teams
• Use velocity as performance metric
• Pressure team to increase velocity
• Game velocity by inflating estimates
• Expect perfectly consistent velocity

Improving Velocity:

• Better story refinement (reduces uncertainty)
• Reduce technical debt (improves efficiency)
• Remove blockers faster
• Limit WIP (improve focus)
• Invest in tools and automation
• Continuous learning and skill development

Velocity Will Decrease If:

• Team size decreases
• Team members are new
• Technical debt increases
• Requirements poorly understood
• Many production issues/interruptions

Definition of Done

The Definition of Done (DoD) ensures consistent quality across all delivered work.

What is Definition of Done?

Definition: A checklist of criteria that all user stories must meet before being marked complete.

Purpose:

• Shared understanding of "done"
• Consistent quality standards
• Prevents incomplete work
• Reduces technical debt
• Enables continuous delivery

Sample Definition of Done

Level 1: Basic DoD

• Code complete and committed
• Acceptance criteria met
• Tested manually
• Product Owner approved

Level 2: Intermediate DoD

• Code complete and merged to main branch
• All acceptance criteria met
• Unit tests written and passing
• Code review completed and approved
• Integration tests passing
• Manual QA testing complete
• No known bugs
• Product Owner approved
• Deployed to staging environment

Level 3: Advanced DoD

• Code complete and merged to main
• All acceptance criteria verified
• Unit test coverage > 80%
• Integration tests passing
• E2E tests passing (if applicable)
• Code review approved (2 reviewers)
• Security scan passed
• Performance tested (meets requirements)
• Accessibility verified (WCAG 2.1 AA)
• Documentation updated (user docs, API docs)
• Product Owner approval
• Deployed to staging
• Ready for production deployment

Creating Your DoD

Team Workshop:

1. Brainstorm quality criteria
2. Discuss current practices
3. Agree on realistic standards
4. Document in team wiki
5. Review and update quarterly

In Waymaker:

• Add DoD to board description
• Reference DoD in task templates
• Use DoD as checklist when reviewing work

Scaling Agile

As your organization grows, you may need to coordinate multiple agile teams.

When to Scale

Indicators:

• Team size > 9 members
• Product too complex for one team
• Multiple related products
• Dependencies between teams

Scaling Frameworks

Scrum of Scrums:

• Multiple Scrum teams coordinate
• Daily Scrum of Scrums meeting
• Representatives from each team
• Discuss dependencies and blockers

SAFe (Scaled Agile Framework):

• Team, Program, Portfolio levels
• Program Increments (PI) planning
• Architectural runway
• Large organizations

LeSS (Large-Scale Scrum):

• One product backlog
• One Product Owner
• Multiple teams
• Minimal scaling overhead

Scaling in Waymaker

Multiple Teams on One Board:

Structure:

Product Development Board
│
├── Epic: Feature A
│   ├── Sprint 5 - Team Alpha
│   │   └── Stories for Team Alpha
│   └── Sprint 5 - Team Beta
│       └── Stories for Team Beta
│
└── Epic: Feature B
    ├── Sprint 5 - Team Alpha
    └── Sprint 5 - Team Beta

Use Tags:

• Tag tasks with team name ("team-alpha", "team-beta")
• Filter by tag to see team-specific work

Multiple Boards (Recommended for Large Scale):

• Separate board per team
• Shared epic board for coordination
• Cross-board dependencies (future feature)

Common Agile Anti-Patterns

Avoid these common mistakes that undermine agile effectiveness.

Sprint Anti-Patterns

❌ Waterfall Sprint:

• Week 1: Design
• Week 2: Development
• No deliverable increment until end

✅ Instead: Deliver complete user stories throughout sprint

❌ Sprint Zero:

• "Setup sprint" with no deliverables
• Infrastructure work with no business value

✅ Instead: Include infrastructure in regular sprints as technical stories

❌ Never-Ending Sprint:

• Sprint extends beyond time-box
• "Just a few more days to finish"

✅ Instead: Accept unfinished work, plan better next time

Planning Anti-Patterns

❌ Product Owner Dictates Commitment:

• "You must complete these 15 stories"
• Team has no say in commitment

✅ Instead: Team self-commits based on capacity

❌ Planning Without Grooming:

• Stories not refined before planning
• Entire planning meeting spent understanding requirements

✅ Instead: Groom backlog weekly, plan only ready stories

❌ Vague Sprint Goal:

• "Complete stories in sprint backlog"
• No cohesive objective

✅ Instead: Specific, achievable goal that provides focus

Backlog Anti-Patterns

❌ 200-Item Backlog:

• Massive unrefined backlog
• Stories from 2 years ago

✅ Instead: Prune backlog quarterly, focus on top 30-50 stories

❌ No Acceptance Criteria:

• "Build the dashboard"
• Team guesses at requirements

✅ Instead: Every story has clear, testable criteria

❌ Everything is High Priority:

• All stories marked critical
• No real prioritization

✅ Instead: Ruthless prioritization, only top 10 are "high"

Execution Anti-Patterns

❌ Ignoring Blockers:

• Daily standup mentions blockers
• No action taken

✅ Instead: Scrum Master actively works to remove impediments

❌ Cherry-Picking Work:

• Team members pick easy stories
• Hard stories left incomplete

✅ Instead: Team commits to sprint goal, tackles hard work first

❌ Skipping Ceremonies:

• "We're too busy to do retrospectives"
• No time for improvement

✅ Instead: Ceremonies are non-negotiable, improve efficiency

Measurement Anti-Patterns

❌ Velocity as Performance Metric:

• "Team Alpha's velocity is higher than Team Beta!"
• Pressure to inflate estimates

✅ Instead: Velocity is for planning, not performance reviews

❌ Individual Velocity Tracking:

• Measuring points per developer
• Destroying team collaboration

✅ Instead: Team velocity only, encourage collaboration

Tips & Best Practices

Sprint Planning:

• Groom backlog weekly - don't plan unrefined stories
• Set clear, achievable sprint goals
• Don't overcommit - use historical velocity
• Involve whole team in planning
• Time-box planning (4 hours max for 2-week sprint)

Story Management:

• Keep stories small (2-8 points ideal)
• Always include acceptance criteria
• Estimate as a team, not individuals
• Use consistent story point scale
• Write from user perspective

Execution:

• Update task status daily
• Limit WIP to 1-2 stories per person
• Finish work before starting new
• Communicate blockers immediately
• Demo work as it's completed (not just at sprint end)

Ceremonies:

• Never skip retrospectives
• Keep standups to 15 minutes
• Invite stakeholders to sprint reviews
• Make retrospectives safe spaces
• Follow up on action items

Continuous Improvement:

• Track velocity trends
• Review and update DoD quarterly
• Experiment with process improvements
• Celebrate sprint goal achievements
• Learn from failures without blame

Related Articles

• Creating Your First Taskboard - Board setup fundamentals
• Interface Overview - Understanding the board interface
• Layer Types Explained - Epic and Sprint layer details
• Using Layers for Agile - Layer-based agile organization
• Kanban Methodology - Continuous flow alternative
• Task Dependencies - Managing story dependencies
• Team Collaboration - Adding team members

Need More Help?

If you have questions about implementing agile methodologies, sprint planning, or using Waymaker for Scrum, please contact support or visit our community forums. Our team can help you design the perfect agile workflow for your team.