Iteration-Based Boards Show Team Commitments

You might have seen a typical Scrum board, similar to the one shown here:

In Scrum and other iteration-based agile approaches, the team estimates what it can commit to for its iteration. The team takes that work and puts it in the Ready column in rank order.

The Ready column does not change during the iteration. This is important. The team, along with the product owner, commits to what the team will do during the iteration. This is one reason why an iteration is different from a cadence. (See ​Distinguish Between Cadence and Iteration​.)

If a team has to manage interruptions, such as support requests, the team leaves room in the iteration for support work. See ​Estimate Support Work​, for more specifics.

The team decides how it will work. The team decides the flow, and the flow is not explicit unless the team decides to make it explicit.

Teams own their own boards. If your team wants to separate support requests from the entire backlog, or add a column labeled “Today,” it should do so. The board exists to help the team members see and finish their work.

Teams that use iterations might even decide to map their flow on their board. As soon as they create WIP limits, the board is technically a kanban board. Does that matter? No, except to the team.

One Scrum team decided that it liked the idea of iterations for cadence, but the members needed to see their flow. As shown in the following figure, they also wanted to have a “Today” and an “Urgent” queue for work. They created a board that looks a lot like a kanban board, which they call their “ScrumFlow” board. (Yes, they made that name up.)

Teams decide what goes on their board. Teams manage their boards. Teams can name their boards. As long as your team’s board provides the team members the data they need to manage themselves, it doesn’t matter what they call the board or what the board shows.