Here’s a Scrumban flow represented in tabular form, outlining how tasks typically move through the system, incorporating aspects of both Scrum (structure and iteration) and Kanban (flow and WIP limits):
🧩 Scrumban Flow Table
| Phase | Description | Key Activities | WIP Limits | Tools/Boards |
|---|---|---|---|---|
| Backlog | A list of all potential tasks and user stories | Backlog grooming, prioritization | No limit | Product backlog board |
| Ready (To Do) | Tasks selected for the next iteration or when team capacity allows | Sprint planning / pull tasks based on capacity | Optional | Sprint backlog / To Do |
| In Progress | Tasks being actively worked on | Development, testing, collaboration | Yes (WIP Limit set) | Work board (In Progress) |
| Review/Testing | Tasks completed and ready for review or QA | Code review, UAT, testing | Yes | QA board |
| Blocked (Optional) | Tasks that can’t proceed due to an external/internal blocker | Waiting for input, resources, or resolution | No work allowed | Separate column |
| Done | Completed and approved tasks ready for release or already delivered | Final review, documentation, deployment | No limit | Done column |
| Retrospective | Evaluate process, team performance, and improvements (regularly) | Team discussion, action items | N/A | Meeting / notes |
⚙️ Key Scrumban Features
- Pull-based: Team members pull tasks into “In Progress” when they have capacity.
- WIP Limits: Set per column to avoid overloading the team.
- No fixed sprints: Tasks are continuously pulled instead of being time-boxed like in Scrum.
- Regular retrospectives: Like Scrum, to continuously improve the process.
- Planning on demand: Instead of fixed sprint planning, plan when the backlog runs low.
