Scrum Team Task Board

By Mark C. Layton

A task board is one way to display the sprint backlog. While it’s common for scrum teams to manage their sprint backlog in a digital format, all you really need for a task board is some wall or whiteboard space, some 3×5 cards and sticky notes, and some tape!

A team task board.
A team task board.

Physical task boards are excellent because they’re a quick and effective way to see the status of the entire sprint at a glance. Having the task board within sight of the development team and product owner ensures that they instantly know what’s done, what’s not, and everything in between. Use these basic elements:

  • Top

    • The specific sprint goal

    • The overall release goal

    Release and sprint dates can also be included.

  • Columns (from left to right)

    • To Do: Those requirements and tasks in the sprint that are yet to be developed.

      Developers pull from the top of this list to start a new task. If more than one developer wants to take the same task, they can either pair on it, one can shadow the other, or they can decide as a team who could best handle it.

    • In Progress: The current product backlog items and tasks that the development team is working on.

      Each task might have different colored dots or stickers to designate ownership, or to identify tasks that are blocked by an impediment. Work in progress (WIP) limits, if used, should be displayed for this column. After developers complete a task, they look here first to see who they can help get to done. Otherwise, they pull the next task from To Do and verify with the team that it’s the right task to start on next.

    • Accept: Those requirements that are awaiting acceptance by the product owner.

      If the requirement is rejected, and enough time is left in the sprint, it goes back to In Progress. Otherwise, the requirement gets moved back to the product backlog for consideration in a future sprint. (This is covered later in this chapter.)

    • Done: The requirements that the product owner has accepted as complete.

While the development team can move the requirements from To Do to In Progress to Accept, only the product owner can move them from Accept to Done. The developers are the only ones who move tasks around on the task board from To Do to In Progress to Accept, and after a requirement is accepted by the product owner and moved to Done, the development team moves tasks with it. Otherwise, if a requirement gets rejected, the development team moves tasks back to In Progress to rework them, or creates new tasks to address the reason that the requirement was rejected.

The physicalness of the task board, like the product roadmap, increases engagement and flexibility with development team members. It’s real. It’s tangible.

Requirements in the Accept column shouldn’t be allowed to pile up. Ideally, you shouldn’t have a day’s break between the card being placed in Accept and either placed in Done or rejected for further development. If a delay occurs, the product owner needs to be coached in not letting stories accumulate waiting to be accepted. You have no reason for delay if the product owner is a dedicated scrum team member who is available to the development team at any time for clarification, the requirements have been detailed down to a single action or integration, and the requirements have passed the definition of done. It’s critical that the development team knows that their work is done and they can “swarm” the next requirement.