Agile & Scrum with Waymaker Taskboards

Difficulty: Intermediate

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

Satisfy customers through early and continuous delivery
Welcome changing requirements, even late in development
Deliver working software frequently (weeks, not months)
Business and developers work together daily
Build projects around motivated individuals
Face-to-face conversation is most effective
Working software is primary measure of progress
Sustainable development at constant pace
Continuous attention to technical excellence
Simplicity - maximize work not done
Self-organizing teams produce best results
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

Navigate to Taskboards
Click "Create Taskboard"
Name: "[Product Name] Development" or "Agile Board - [Team Name]"
Type: Project
Description: Product vision and team information
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:

Board Settings → Sections
Add/rename sections as above
Set "Done" as completion status
Save changes

Step 3: Define Your Epics

Identify major feature areas or themes:

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

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

Step 4: Create Product Backlog Layer

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

Step 5: Create Your First Sprint

Select parent epic in Layer Manager
Add Sub-layer → Type: Sprint
Name: "Sprint 1: Oct 14-27" (number and dates)
Description: Sprint goal and team capacity
Dates: Exact start and end (critical)
Color: Blue (#3B82F6) - consistent for all sprints
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

Layer Manager → Add Layer
Type: Epic
Name: "Advanced Reporting Dashboard"
Description: Paste epic description above
Dates: Oct 14 - Dec 22 (estimated epic duration)
Color: Purple
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)

Review Sprint Goal Candidates
- Product Owner presents goal options
- Team discusses and selects primary goal
- Goal should be achievable in one sprint

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

Select User Stories
- Start with highest priority stories
- Pull stories that support sprint goal
- Stop when capacity reached
- Don't overcommit

In Waymaker:

Filter board to "Product Backlog" layer
Sort by priority
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)

Break Down Stories
- Discuss implementation approach
- Identify tasks within stories
- Estimate effort
- Identify dependencies
Identify Risks
- Technical unknowns
- External dependencies
- Resource constraints
- Potential blockers
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

Navigate to board
Click "+" in Backlog section
Enter user story title
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:

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

Benefits:

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

Relative Sizing:

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

Benefits:

Fast estimation
Leverages team knowledge
Consistent over time

T-Shirt Sizing (Then Convert):

Estimate as XS, S, M, L, XL
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

Open task editor
Find "Estimate (points)" field
Enter story point value
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

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

Review top 15-20 stories
Product Owner explains each story
Team asks clarifying questions
Add acceptance criteria
Estimate story points
Identify dependencies
Mark stories as "Ready for Sprint"

Week 2: Focus on Sprint N+2

Review next 15-20 stories
Initial estimates
Identify research needs
Break down epics into stories

In Waymaker:

Filter to "Product Backlog" layer
Sort by priority
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
Use comments to capture discussion points
@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:

Business Value: Revenue impact, strategic importance
User Value: User satisfaction, feature requests
Risk Reduction: Technical unknowns, dependencies
Dependencies: Prerequisite for other work
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:

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

Sprint Execution and Daily Standups

Once sprint planning is complete, execution begins.

Sprint Kickoff

Day 1 of Sprint:

Team aligns on sprint goal
Review sprint backlog
Team members self-assign first stories
Identify any immediate blockers
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:

What did I complete yesterday?
- Focus on completed work
- Reference specific tasks
What will I work on today?
- State commitment
- Mention task names
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

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

Option 2: List View

Filter to current sprint + assigned to each person
Quick review of each person's tasks
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:

Product Owner evaluates urgency
Team assesses impact
If must add work, remove equivalent work from sprint
Document change in sprint description
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:

Filter to current sprint layer
Filter to "Done" section
Review each completed story
Check all acceptance criteria met
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:

Create task for each action item
Assign to owner
Add to next sprint
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:

Review previous action items
Discuss: What happened? Did it help?
Celebrate completed actions
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:

Sum story points of all completed stories
Only count stories meeting Definition of Done
Record velocity for sprint
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:

Filter to sprint layer
Filter to "Done" section
Sum story points of completed tasks
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

Level 3: Advanced DoD

Creating Your DoD

Team Workshop:

Brainstorm quality criteria
Discuss current practices
Agree on realistic standards
Document in team wiki
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

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.

Agile & Scrum with Waymaker Taskboards

Agile & Scrum with Waymaker Taskboards

Overview

What You'll Learn

Prerequisites

Agile Principles and Values

The Agile Manifesto

Twelve Agile Principles

Agile in Waymaker

The Scrum Framework

Scrum Roles

Scrum Events (Ceremonies)

Scrum Artifacts

Setting Up Your Agile Board

Recommended Board Structure

Step-by-Step Board Creation

Creating and Managing Epics

What Makes a Good Epic?

Epic Creation Process

Epic Sizing Guidelines

Sprint Planning and Management

Pre-Planning Preparation

Sprint Planning Meeting

User Story Creation and Estimation

User Story Format

INVEST Criteria

Creating User Stories in Waymaker

Acceptance Criteria Best Practices

Story Point Estimation

Story Point Scale

What Story Points Represent

Estimation Guidelines

Estimation Techniques

Setting Estimates in Waymaker

Backlog Management and Grooming

Product Backlog Structure

Backlog Refinement (Grooming)

Definition of Ready

Backlog Prioritization

Sprint Execution and Daily Standups

Sprint Kickoff

Daily Standup

Work in Progress (WIP) Limits

Managing Sprint Changes

Sprint Review and Demo

Sprint Review Meeting

Review Agenda

Preparing for Sprint Review

Accepting or Rejecting Work

Sprint Retrospective

Retrospective Meeting

Retrospective Format

Documenting Retrospective in Waymaker

Following Up on Action Items

Velocity Tracking and Forecasting

Calculating Velocity

Velocity in Waymaker

Using Velocity for Planning

Velocity Best Practices

Definition of Done

What is Definition of Done?

Sample Definition of Done

Creating Your DoD

Scaling Agile

When to Scale

Scaling Frameworks

Scaling in Waymaker

Common Agile Anti-Patterns

Sprint Anti-Patterns

Planning Anti-Patterns

Backlog Anti-Patterns

Execution Anti-Patterns

Measurement Anti-Patterns

Tips & Best Practices

Related Articles

Need More Help?