Waymaker

Using Layers for Agile Projects

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

Overview

Agile methodology and Waymaker layers are a perfect match. Layers provide the hierarchical structure needed to organize epics, sprints, and user stories, while maintaining the flexibility and iterative nature that makes agile so effective. This comprehensive guide shows you how to set up and run agile projects using Waymaker taskboards, from initial board structure through sprint planning, execution, and retrospectives.

Whether you're a Scrum Master setting up your first agile board, a Product Owner managing a backlog, or a development team member tracking sprint work, this article provides the patterns, workflows, and best practices you need to succeed with agile in Waymaker.

What You'll Learn

  • How to structure agile boards with epics and sprints
  • Complete agile workflow from backlog to sprint completion
  • Sprint planning process using layers and tasks
  • User story creation and sizing with story points
  • Tracking sprint velocity and burndown
  • Managing product backlog and grooming
  • Sprint review and retrospective workflows
  • Recommended layer structures for different agile scenarios
  • Best practices for agile teams using Waymaker

Prerequisites

Agile Board Setup

Setting up your agile board correctly from the start creates a foundation for smooth sprint planning and execution.

Recommended Agile Board Structure

The most effective agile board structure uses a two-level hierarchy:

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

Example Structure:

Product Development Board
├── Epic: User Authentication
│   ├── Sprint 10: Oct 1-14
│   │   ├── User Story: Login page UI
│   │   ├── User Story: OAuth integration
│   │   └── User Story: Password validation
│   └── Sprint 11: Oct 15-28
│       ├── User Story: Password reset flow
│       └── User Story: Two-factor authentication
├── Epic: Dashboard Features
│   ├── Sprint 11: Oct 15-28
│   │   ├── User Story: Analytics widgets
│   │   └── User Story: Custom dashboards
│   └── Sprint 12: Oct 29-Nov 11
├── Epic: Reporting System
│   └── Sprint 12: Oct 29-Nov 11
└── Custom: Product Backlog
    └── Unscheduled user stories

Step-by-Step: Creating Your Agile Board

Step 1: Create the Board

  1. Navigate to Taskboards
  2. Click "Create Taskboard"
  3. Name: "Product Development" (or your product/project name)
  4. Type: Project (for full layer and collaboration features)
  5. Description: Brief overview of the product or project
  6. Create the board

Step 2: Set Up Workflow Sections

Customize your Kanban columns to match agile workflow:

Recommended Sections:

  • Backlog: Unrefined, unscheduled stories
  • To Do: Sprint committed stories ready to start
  • In Progress: Stories actively being worked
  • Review: Stories in code review or QA
  • Done: Completed stories (mark as complete)

To Customize:

  1. Open Board Settings
  2. Navigate to Sections tab
  3. Rename or add sections as needed
  4. Set "Done" section as completion status

Step 3: Create Epic Layers

Identify your major features or themes:

  1. Open Layer Manager
  2. Click "Add Layer"
  3. Type: Epic
  4. Name: Descriptive feature name (e.g., "User Authentication")
  5. Description: Feature scope and goals
  6. Dates: Estimated start and end (flexible)
  7. Color: Purple (or consistent epic color)
  8. Create layer

Repeat for each major feature area. Typical products have 3-8 active epics at any time.

Step 4: Create a Backlog Layer

Create a custom layer for unscheduled stories:

  1. Add Layer
  2. Type: Custom
  3. Name: "Product Backlog" or "Unscheduled"
  4. Description: "User stories not yet assigned to a sprint"
  5. Color: Gray or neutral color
  6. Create layer

Step 5: Create Your First Sprint Layer

Under an epic, create a sprint:

  1. Select parent epic in Layer Manager
  2. Click "Add Sub-layer"
  3. Type: Sprint
  4. Name: "Sprint 10: Oct 1-14" (include number and dates)
  5. Description: Sprint goal and capacity
  6. Dates: Exact start and end dates (critical)
  7. Color: Blue (or consistent sprint color)
  8. Create layer

Your board is now ready for sprint planning!

Creating Epics as Top-Level Layers

Epics are the backbone of agile organization, representing large bodies of work that span multiple sprints.

What Makes a Good Epic?

Size: Too large for one sprint (typically 3-8 sprints)

Value: Delivers meaningful business or user value

Theme: Cohesive feature set or functional area

Breakdown: Can be decomposed into user stories

Estimation: Roughly sized (in story points or weeks)

Epic Creation Process

Step 1: Identify Epic Opportunities

Sources for epics:

  • Product roadmap initiatives
  • Customer feature requests (grouped)
  • Technical infrastructure needs
  • User experience improvements
  • Platform expansion (mobile, API, etc.)

Step 2: Write Epic Description

A complete epic description includes:

## Epic: User Authentication System

### Business Value
Enable users to securely access their accounts, supporting our goal
of 10,000 registered users by Q4.

### User Impact
Users can:
- Create accounts with email or social login
- Securely log in and out
- Reset forgotten passwords
- Enable two-factor authentication for enhanced security

### Scope
Included:
- Login/logout functionality
- Account creation and email verification
- OAuth integration (Google, GitHub)
- Password reset flow
- Two-factor authentication (TOTP)

Excluded (for future epics):
- SSO / SAML integration
- Biometric authentication
- Account recovery options beyond email

### Success Criteria
- 95% of users can successfully create accounts
- Login success rate > 98%
- Password reset completion rate > 80%
- < 0.1% authentication-related support tickets

### Estimated Effort
3 sprints (6 weeks), approximately 120 story points

### Dependencies
- User database schema finalized
- Email service configured
- SSL certificates for production

Step 3: Create Epic Layer in Waymaker

  1. Open Layer Manager
  2. Add Layer → Type: Epic
  3. Name: "User Authentication System"
  4. Description: Paste your epic description
  5. Dates: Oct 1 - Nov 15 (estimated)
  6. Color: Purple (#8B5CF6)
  7. Create

Step 4: Decompose into User Stories

Break the epic into user stories:

  • As a user, I can create an account with email and password
  • As a user, I can verify my email address
  • As a user, I can log in with my credentials
  • As a user, I can log in with Google OAuth
  • As a user, I can log in with GitHub OAuth
  • As a user, I can reset my forgotten password
  • As a user, I can enable two-factor authentication
  • As a user, I can use 2FA to log in securely

Create these as tasks in the Backlog layer initially. They'll move to sprint layers during sprint planning.

Epic Naming Best Practices

Good Epic Names:

  • ✅ "User Authentication System"
  • ✅ "Advanced Reporting Dashboard"
  • ✅ "Mobile App - iOS Version"
  • ✅ "Payment Processing & Invoicing"
  • ✅ "Multi-language Support (i18n)"

Poor Epic Names:

  • ❌ "Feature A" (not descriptive)
  • ❌ "Big Project" (too vague)
  • ❌ "Improvements" (not specific)
  • ❌ "Epic 1" (not meaningful)

Naming Pattern: [Feature Area]: [Specific Capability]

Creating Sprints as Sub-layers with Dates

Sprints are time-boxed iterations—the heartbeat of your agile delivery. Each sprint must have exact dates.

Sprint Fundamentals

Duration: 1-4 weeks (2 weeks most common)

Time-boxed: Fixed start and end dates, non-negotiable

Goal-oriented: Each sprint has a specific objective

Team commitment: Team commits to completing planned work

Deliverable: Produces shippable product increment

Sprint Creation Process

Step 1: Determine Sprint Schedule

Plan your sprint calendar:

Example: 2-week sprints

  • Sprint 10: Oct 1-14
  • Sprint 11: Oct 15-28
  • Sprint 12: Oct 29 - Nov 11
  • Sprint 13: Nov 12-25

Tips:

  • Avoid starting/ending on holidays
  • Account for team time off
  • Keep duration consistent
  • Number sprints sequentially

Step 2: Create Sprint Layer

  1. Open Layer Manager
  2. Find the parent epic
  3. Click "Add Sub-layer"
  4. Type: Sprint
  5. Name: "Sprint 10: Oct 1-14"
  6. Description: Sprint goal and capacity
  7. Dates: Oct 1, 2025 (start) to Oct 14, 2025 (end)
  8. Color: Blue (#3B82F6)
  9. Create layer

Step 3: Define Sprint Goal

Add a clear sprint goal in the description:

## Sprint 10: Authentication Core

### Sprint Goal
Implement core authentication infrastructure including login UI,
OAuth integration, and basic password validation.

### Team Capacity
- Team size: 5 developers
- Sprint length: 10 working days
- Capacity: 40 story points (based on recent velocity)
- Time off: None planned

### Key Deliverables
- Functional login page
- Google OAuth working
- GitHub OAuth working
- Password validation implemented
- Unit test coverage > 80%

### Success Criteria
- Demo-able login flow
- OAuth providers functional
- Tests passing

Sprint Naming Conventions

Recommended Pattern: Sprint [Number]: [Month Day]-[Day]

Examples:

  • ✅ "Sprint 10: Oct 1-14"
  • ✅ "Sprint 2025-10 (Oct 1-14)"
  • ✅ "Q4 Sprint 3: Oct 1-14"

Alternative Patterns:

  • "Sprint 10" (simple, requires date in properties)
  • "Oct 1-14 Sprint" (date-first)
  • "MVP Sprint 3" (milestone-based numbering)

Avoid:

  • ❌ "Current Sprint" (not specific, confusing when archived)
  • ❌ "October Sprint" (ambiguous if multiple sprints)
  • ❌ "Sprint A" (not sequential)

Cross-Epic Sprints

In reality, a single sprint often contains user stories from multiple epics. Handle this in two ways:

Option 1: Sprint as Child of Primary Epic

Create the sprint under the epic with the most stories:

Epic: User Authentication
├── Sprint 10: Oct 1-14 (primary focus: authentication)
│   ├── Auth Story 1 (in this epic)
│   ├── Auth Story 2 (in this epic)
│   └── Dashboard Story (actually belongs to Dashboard epic)

Option 2: Sprint as Root Layer

Create sprints as root layers, separate from epics:

Sprint 10: Oct 1-14 (root layer)
├── Auth Story 1 (epic: User Authentication)
├── Auth Story 2 (epic: User Authentication)
└── Dashboard Story (epic: Dashboard Features)

Epic: User Authentication (root layer)
├── All auth-related stories, regardless of sprint

Epic: Dashboard Features (root layer)
├── All dashboard-related stories, regardless of sprint

Recommendation: Use Option 1 for simplicity if sprints are mostly focused on one epic. Use Option 2 for balanced, cross-epic sprints.

User Stories as Tasks

In Waymaker, user stories are implemented as tasks assigned to layers (sprints and epics).

User Story Format

Use the standard agile format:

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

Examples:

  • "As a user, I can log in with my email and password, so that I can access my account"
  • "As a user, I can reset my forgotten password, so that I can regain access to my account"
  • "As an admin, I can view user login history, so that I can monitor for suspicious activity"

Creating User Stories in Waymaker

Step 1: Create the Task

  1. Navigate to your taskboard
  2. Click "+" in the appropriate section (typically "Backlog" or "To Do")
  3. Enter the user story title
  4. Task modal opens

Step 2: Fill in Story Details

Title: User story in format above

Description:

## User Story
As a user, I can log in with my email and password, so that I can
access my account.

## Acceptance Criteria
- [ ] Login form with email and password fields
- [ ] "Remember me" checkbox
- [ ] "Forgot password?" link
- [ ] Form validation (required fields, email format)
- [ ] Success: Redirect to dashboard
- [ ] Failure: Show error message
- [ ] Loading state during authentication

## Technical Notes
- Use JWT for session management
- Hash passwords with bcrypt
- Rate limit login attempts (5 per minute)

## Design
[Link to Figma mockup]

## Testing
- Unit tests for validation logic
- Integration test for login flow
- E2E test for full user journey

Layer: Assign to sprint layer (e.g., "Sprint 10: Oct 1-14") OR to "Product Backlog" if not yet scheduled

Estimate (points): Story point estimate (see next section)

Priority: High/Medium/Low based on product priorities

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

Tags: Add tags like "frontend", "backend", "design-needed"

Step 3: Create the Task

Click "Create Task" to save.

Acceptance Criteria

Every user story should have clear acceptance criteria—the definition of "done" for that story.

Format: Checklist

Use a checklist in the task description:

## Acceptance Criteria
- [ ] User can enter email and password
- [ ] Form validates email format
- [ ] Form validates required fields
- [ ] Clicking "Login" submits credentials
- [ ] Success redirects to dashboard
- [ ] Failure shows error message
- [ ] Loading indicator during submission

Or: Gherkin Format (BDD)

## Acceptance Criteria

**Scenario: Successful Login**
Given I am on the login page
When I enter valid email and password
And I click "Login"
Then I am redirected to my dashboard
And I see a success message

**Scenario: Invalid Credentials**
Given I am on the login page
When I enter invalid email or password
And I click "Login"
Then I see an error message "Invalid credentials"
And I remain on the login page

Benefits:

  • Clear definition of done
  • Testable criteria
  • Shared understanding between product and dev
  • Basis for QA testing

Story Points and Estimation

Story points measure the effort, complexity, and uncertainty of a user story relative to other stories.

Story Point Scale

Most teams use Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21

Why Fibonacci? Reflects increasing uncertainty at larger sizes.

What Story Points Represent

Effort: How much work is required?

Complexity: How difficult or intricate is the work?

Uncertainty: How well do we understand the requirements?

Not Time: Story points are relative, not hours or days

Estimation Guidelines

1 point: Trivial change

  • Fix typo in UI text
  • Update color constant
  • Add simple validation

2 points: Simple task

  • Add new form field
  • Create basic API endpoint
  • Write unit test for existing function

3 points: Standard story

  • Implement CRUD for simple entity
  • Create new UI component
  • Add authentication to endpoint

5 points: Moderate complexity

  • Implement login flow
  • Create complex form with validation
  • Integrate third-party API

8 points: Complex story

  • OAuth integration
  • Advanced search with filters
  • Real-time collaboration feature

13 points: Very complex

  • Complete authentication system
  • Payment processing integration
  • Reporting dashboard with charts

21+ points: Epic-sized

  • Too large for one sprint
  • Break down into smaller stories
  • Example: Entire user management system

Estimation Process

Planning Poker:

  1. Read user story aloud
  2. Discuss acceptance criteria and scope
  3. Each team member privately selects estimate
  4. Reveal estimates simultaneously
  5. Discuss differences (especially outliers)
  6. Re-estimate until consensus

Relative Sizing:

  • Compare to previously completed stories
  • "This is similar to Story X, which was 5 points"
  • "This is about twice as complex as Story Y"

Setting Story Points in Waymaker

When creating or editing a task:

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

Tip: Set estimates during sprint planning or backlog grooming, not when creating the story initially.

Sprint Planning Workflow

Sprint planning is where you decide what the team will accomplish in the upcoming sprint.

Sprint Planning Meeting

Duration: 2-4 hours for 2-week sprint

Attendees: Entire Scrum team (Product Owner, Scrum Master, Developers)

Outputs:

  • Sprint goal defined
  • User stories selected and committed
  • Stories assigned to sprint layer
  • Team commitment and buy-in

Sprint Planning Process in Waymaker

Step 1: Review Sprint Capacity

Before the meeting, calculate team capacity:

Team Capacity = (Team Members) × (Working Days) × (Focus Factor)

Example:
- Team: 5 developers
- Sprint: 10 working days
- Focus factor: 70% (accounts for meetings, interruptions)
- Story point capacity: 40 points (based on past velocity)

Add capacity to sprint description.

Step 2: Set Sprint Goal

Define a clear, concise sprint goal:

Examples:

  • "Implement core authentication infrastructure"
  • "Complete dashboard analytics widgets"
  • "Launch beta version for user testing"

Add goal to sprint layer description.

Step 3: Review and Refine Backlog

  1. Filter taskboard to show "Product Backlog" layer
  2. Ensure top stories have:
    • Clear descriptions
    • Acceptance criteria
    • Story point estimates
    • Priority set
  3. Product Owner explains top-priority stories
  4. Team asks clarifying questions

Step 4: Select Stories for Sprint

  1. Starting with highest priority stories:
    • Does this story align with sprint goal?
    • Do we have capacity for this story?
    • Do we understand the requirements?
  2. If yes to all, move story to sprint:
    • Open task editor
    • Change Layer from "Product Backlog" to "Sprint 10: Oct 1-14"
    • Change Section to "To Do"
    • Save task
  3. Repeat until capacity reached

Capacity Check:

Selected Stories Total: 38 points
Sprint Capacity: 40 points
Status: Good (90-100% of capacity)

Don't overcommit: Aim for 80-100% of capacity, not 120%.

Step 5: Break Down Large Stories (If Needed)

If a story is too large (8+ points):

  • Can we break it into smaller stories?
  • Can we reduce scope to fit this sprint?
  • Or defer to next sprint?

Step 6: Team Commits

Final check:

  • "Can we complete these stories in this sprint?"
  • "Is everyone comfortable with the commitment?"
  • If yes → Sprint commitment made
  • If no → Adjust scope (remove stories or reduce)

After Sprint Planning

Update Board:

  • All sprint stories in "To Do" section
  • Sprint layer description has goal and capacity
  • Stories have estimates and acceptance criteria

Ready to Start:

  • Team picks up first stories
  • Daily standups begin
  • Sprint is underway!

Backlog Management

The product backlog is the single source of truth for all potential work. Good backlog management is critical to agile success.

Backlog Layer Setup

Create a custom "Product Backlog" layer:

Product Backlog (Custom Layer)
└── All unscheduled user stories

Or organize by epic:

Epic: User Authentication
├── Scheduled stories (in sprints)
└── Unscheduled stories (backlog)

Epic: Dashboard
└── Unscheduled stories (backlog)

Backlog Grooming (Refinement)

Frequency: Weekly or bi-weekly

Duration: 1-2 hours

Attendees: Product Owner + 2-3 team members (rotating)

Activities:

1. Review New Stories

  • Product Owner presents new stories added since last grooming
  • Team asks questions, discusses technical approach
  • Estimate story points
  • Set initial priority

2. Refine Upcoming Stories

  • Focus on top 10-20 stories in backlog
  • Add acceptance criteria
  • Break down large stories
  • Update estimates if understanding has improved
  • Identify dependencies or blockers

3. Re-prioritize

  • Move stories up or down based on business value
  • Consider dependencies and logical sequencing
  • Mark stories as "Ready for Sprint" when fully refined

4. Remove Obsolete Stories

  • Delete stories that are no longer relevant
  • Archive stories for potential future consideration

Backlog Prioritization in Waymaker

Use Priority Field:

  • Set task priority: High, Medium, Low
  • High = Top of backlog (pull into next sprint)
  • Medium = Near-term (next 2-3 sprints)
  • Low = Future consideration

Use List View:

  1. Switch to List view
  2. Filter to "Product Backlog" layer
  3. Sort by Priority (High → Low)
  4. Drag to reorder within priority levels
  5. Top stories are "Ready for Sprint"

Visual Indicators:

  • High priority stories in "Backlog" section
  • Lower priority in "Icebox" section (if you create one)

Definition of Ready

A user story is "Ready for Sprint" when it meets these criteria:

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

In Waymaker: Use tags or checklist in description to mark stories as "Ready".

Sprint Velocity Tracking

Velocity is the average number of story points your team completes per sprint. It's the foundation of predictable planning.

Calculating Velocity

After Each Sprint:

  1. Sum story points of all completed stories
  2. Record velocity for that sprint
  3. Calculate rolling average (last 3-5 sprints)

Example:

Sprint 7: 38 points completed
Sprint 8: 42 points completed
Sprint 9: 36 points completed
Sprint 10: 40 points completed

Average Velocity: (38 + 42 + 36 + 40) / 4 = 39 points per sprint

Tracking Velocity in Waymaker

Manual Tracking (Current):

  1. At end of sprint, filter to sprint layer
  2. Filter to "Done" section
  3. Sum story points of completed tasks
  4. Record in sprint description:
## Sprint 10: Retrospective

### Velocity
- Committed: 40 points
- Completed: 38 points
- Velocity: 38 points
- Team: 5 developers
- Sprint length: 2 weeks

### Completion Rate
95% (38/40)

Dashboard View (Future Feature):

  • Automatic velocity calculation
  • Velocity trend chart
  • Burndown/burnup charts

Using Velocity for Planning

Predictable Planning:

  • If average velocity is 39 points
  • Plan next sprint for ~39 points
  • Don't overcommit to 50+ points

Release Forecasting:

Remaining Epic Work: 120 points
Average Velocity: 39 points per sprint
Estimated Sprints: 120 / 39 = 3.1 sprints (~7 weeks)

Improving Velocity:

  • Reduce context switching
  • Improve story refinement
  • Address technical debt
  • Optimize team collaboration
  • Remove blockers faster

Sprint Review and Retrospectives

Each sprint ends with two critical ceremonies: Review and Retrospective.

Sprint Review (Demo)

Purpose: Demonstrate completed work to stakeholders

Duration: 1-2 hours for 2-week sprint

Attendees: Scrum team + stakeholders

Agenda:

  1. Review sprint goal
  2. Demo each completed user story
  3. Accept or reject stories (meets acceptance criteria?)
  4. Discuss feedback and potential changes
  5. Update product backlog based on feedback

In Waymaker:

Prepare for Review:

  1. Filter to sprint layer
  2. Filter to "Done" section
  3. Review each completed story
  4. Ensure all acceptance criteria met
  5. Demo in order of user journey (not random)

After Review:

  • Mark accepted stories as complete
  • Move unfinished stories to next sprint or backlog
  • Create new stories from feedback

Sprint Retrospective

Purpose: Reflect on the sprint and identify improvements

Duration: 1-1.5 hours for 2-week sprint

Attendees: Scrum team only (no stakeholders)

Agenda:

  1. What went well?
  2. What didn't go well?
  3. What should we try next sprint?
  4. Create action items

Documenting Retrospectives in Waymaker:

Add retrospective notes to sprint description:

## Sprint 10: Retrospective

### Date
October 14, 2025

### What Went Well
- OAuth integration smoother than expected
- Good collaboration between frontend and backend
- Effective code reviews caught issues early

### What Didn't Go Well
- Authentication story was underestimated (should have been 8 points, not 5)
- Two team members out sick for 2 days
- Design mockups arrived late in sprint

### Action Items for Next Sprint
- [ ] Improve estimation for authentication-related stories
- [ ] Request designs 1 week before sprint starts
- [ ] Add buffer time for unexpected absences (plan for 90% capacity)

### Metrics
- Velocity: 38 points
- Stories completed: 9 of 10
- Sprint goal: Achieved ✅

Track Action Items: Create tasks for retrospective action items, assign to next sprint.

Recommended Agile Board Structure

Here's a complete, production-ready agile board structure you can use as a template:

Complete Structure

Product Development Board
│
├── Epic: User Authentication (Purple)
│   ├── Sprint 10: Oct 1-14 (Blue) - COMPLETED
│   │   ├── Story: Login UI (Done)
│   │   ├── Story: OAuth integration (Done)
│   │   └── Story: Password validation (Done)
│   ├── Sprint 11: Oct 15-28 (Blue) - ACTIVE
│   │   ├── Story: Password reset (In Progress)
│   │   └── Story: Two-factor auth (To Do)
│   └── Sprint 12: Oct 29-Nov 11 (Blue) - PLANNED
│       └── Unassigned stories
│
├── Epic: Dashboard Features (Purple)
│   ├── Sprint 11: Oct 15-28 (Blue) - ACTIVE
│   │   ├── Story: Analytics widgets (In Progress)
│   │   └── Story: Custom dashboards (To Do)
│   └── Sprint 12: Oct 29-Nov 11 (Blue) - PLANNED
│
├── Epic: Reporting System (Purple)
│   └── Sprint 12: Oct 29-Nov 11 (Blue) - PLANNED
│
├── Custom: Product Backlog (Gray)
│   ├── Unscheduled auth stories
│   ├── Unscheduled dashboard stories
│   ├── Unscheduled reporting stories
│   └── New feature requests
│
└── Milestone: MVP Launch (Gold)
    Date: November 15, 2025

Section Structure

Sections (Kanban columns):
├── Backlog (not yet committed)
├── To Do (committed to sprint, not started)
├── In Progress (actively being worked)
├── Review (in code review or QA)
└── Done (completed, meets acceptance criteria)

Recommended Workflow

Ongoing:

  • Product Owner adds stories to Product Backlog layer
  • Team grooms backlog weekly
  • Stories move from Backlog → To Do → In Progress → Review → Done

Every 2 Weeks (Sprint Cycle):

  1. Sprint Planning: Select stories from backlog, assign to new sprint layer
  2. Daily Standups: Update task status and assignments
  3. Sprint Review: Demo completed work
  4. Sprint Retrospective: Reflect and improve
  5. Repeat: Plan next sprint

Agile Best Practices with Waymaker Layers

Layer Organization

Epic Guidelines:

  • 3-8 active epics at any time
  • Each epic represents 2-6 sprints of work
  • Use purple color consistently
  • Epic descriptions include business value and success criteria

Sprint Guidelines:

  • Create sprints 1-2 sprints ahead
  • Always include exact start and end dates
  • Use blue color consistently
  • Sprint descriptions include goal and capacity
  • Archive completed sprints after retrospective (future feature)

Backlog Guidelines:

  • Single "Product Backlog" custom layer for unscheduled work
  • Keep backlog prioritized (use Priority field)
  • Groom weekly
  • Top 10-20 stories always "Ready for Sprint"

Story Management

Estimation:

  • Estimate all backlog stories within 2 sprints of pulling into sprint
  • Use planning poker for team alignment
  • Re-estimate if understanding changes significantly
  • Don't estimate too far ahead (priorities change)

Acceptance Criteria:

  • Every story has clear, testable acceptance criteria
  • Use checklists in task description
  • Review criteria before starting story
  • QA uses criteria to validate completion

Story Size:

  • Most stories: 2-8 points
  • Stories > 13 points: Break down before sprint planning
  • Stories = 1 point: Consider batching several together
  • Goal: 5-10 stories per sprint for most teams

Sprint Execution

Daily Standups:

  • Use Kanban view filtered to current sprint
  • Each team member updates task status
  • Move tasks across sections (To Do → In Progress → Done)
  • Identify blockers (mark with tags or comments)

WIP Limits:

  • Limit "In Progress" to 1-2 stories per developer
  • Finish stories before starting new ones
  • Avoid context switching

Transparency:

  • Update task status daily
  • Add comments when stuck or need help
  • Tag team members with @mentions
  • Keep sprint board current at all times

Metrics and Improvement

Track:

  • Velocity (story points per sprint)
  • Commitment reliability (% of committed work completed)
  • Cycle time (days from To Do → Done)
  • Sprint goal achievement rate

Review:

  • Velocity trends (improving, stable, declining?)
  • Story estimation accuracy (re-estimations needed?)
  • Sprint goal achievement (hitting goals consistently?)
  • Team satisfaction (from retrospectives)

Improve:

  • Use retrospective action items to drive improvement
  • Experiment with process changes
  • Celebrate wins and learn from misses
  • Continuously refine your agile practice

Tips & Best Practices

  • Consistent Sprint Length: Keep all sprints the same duration (typically 2 weeks)
  • Clear Sprint Goals: Every sprint should have a specific, achievable goal
  • Don't Skip Ceremonies: Sprint planning, review, and retrospective are essential
  • Groom Regularly: Weekly backlog grooming prevents planning surprises
  • Estimate Together: Use planning poker for team alignment and shared understanding
  • Track Velocity: Use velocity for realistic planning, not as a performance metric
  • Limit WIP: Finish stories before starting new ones to improve flow
  • Daily Updates: Keep task status current for transparency and collaboration
  • Celebrate Success: Mark sprint completions and achievements
  • Archive Completed Sprints: Keep active board clean (future feature)

Common Mistakes to Avoid

  • Overcommitting: Planning for more points than your velocity supports
  • Skipping Dates: Not setting exact start/end dates on sprint layers
  • Poor Estimates: Not involving whole team in estimation process
  • Large Stories: Pulling 13+ point stories into sprint without breaking down
  • No Sprint Goal: Creating sprints without clear objectives
  • Ignoring Velocity: Planning based on hope rather than historical data
  • Backlog Chaos: Not grooming backlog regularly, leading to poorly understood stories
  • Changing Mid-Sprint: Adding or removing stories during sprint (scope creep)
  • No Retrospectives: Skipping retrospectives and missing improvement opportunities
  • Status Staleness: Not updating task status daily, losing transparency

Related Articles

Need More Help?

If you have questions about setting up agile workflows, sprint planning, or using layers for agile projects, please contact support or visit our community forums. Our team can help you design the perfect agile workflow for your team.