Sprint length / iteration length by methodology
| Methodology | Correct term | Typical length | Explanation |
|---|---|---|---|
| Agile | Iteration / sprint, depending on framework | Usually 1–4 weeks | Agile is a broad mindset, not one fixed process. Different Agile frameworks use different time-boxes. |
| Scrum | Sprint | Usually 1–4 weeks | Scrum uses a fixed-length sprint to plan, build, review, and improve. Your slides define a sprint as a time-boxed period of 1–4 weeks that creates a potentially shippable product increment. |
| XP / Extreme Programming | Iteration | Usually 1–2 weeks, sometimes up to 3 weeks | XP uses short iterations to support frequent feedback, continuous integration, testing, refactoring, and small releases. |
| Kanban | No sprint required | No fixed sprint length | Kanban is based on continuous flow. Work is pulled through the board as capacity becomes available, rather than being planned into fixed sprints. Your slides describe Kanban as continuous flow with no fixed iterations. |
Simple explanation
A sprint is a fixed time-box used mainly in Scrum. For example, a team may choose a 2-week sprint. At the beginning, they plan the work. During the sprint, they execute and track progress. At the end, they review the completed increment and hold a retrospective.
In XP, the idea is similar, but the term iteration is more common. XP iterations are usually short because XP emphasizes quick feedback, frequent releases, testing, and continuous improvement.
In Kanban, there is normally no sprint length because work flows continuously. Instead of saying, “What can we finish in the next two weeks?”, a Kanban team asks, “What is the next highest-priority item we can pull now, based on available capacity and WIP limits?”
For students, you can say:
Scrum works in fixed sprints. XP works in short iterations. Kanban works in continuous flow. Agile is the umbrella concept that can include all of these approaches.
WIP Limits:
WIP limits means Work-In-Progress limits.
In Kanban, a WIP limit sets the maximum number of work items allowed in one workflow stage at the same time. For example, a team may decide that only 3 user stories can be in In Progress at once. Your slides define WIP limits as a constraint-based approach used to optimize flow and prevent overloading the team.
| Term | Meaning |
| WIP | Work currently started but not yet finished |
| WIP Limit | Maximum number of items allowed in a stage |
| Purpose | Prevent too much work from being started at once |
| Benefit | Helps reveal bottlenecks and improves delivery speed |
| Common Kanban columns | Backlog → To Do → In Progress → Review/Testing → Done |
Example:
| Kanban Column | WIP Limit | Meaning |
| To Do | No limit | Work waiting to be started |
| In Progress | 3 | Only 3 items can be actively worked on |
| Review / Testing | 2 | Only 2 items can wait for review/testing |
| Done | No limit | Completed work |
Simple explanation:
WIP limits stop the team from starting too many things at the same time. Instead of everyone beginning new tasks, the team focuses on finishing existing work first.
What the action looks like:
A team has 3 stories already in In Progress, and the WIP limit is 3. A developer cannot pull another story into In Progress until one of the current stories moves to Review or Done.
This helps the team ask:
“Why is work stuck here?”
“Do we need to help finish current work before starting new work?”
“Is testing or review becoming a bottleneck?”
In Jira or a Kanban board, WIP limits usually appear as a number on top of a column, such as:
In Progress 3/3
That means the column is full. The team should finish or move existing work before starting more.
