In software projects managed with tools such as Jira or Azure DevOps, it is common practice to visualize tasks and user stories on a board. This board helps the entire team to track the status of the work and identify potential bottlenecks in the workflow. During daily stand-up meetings, the progress of the current development iteration is discussed based on the board.

How to work with such a task board in an agile project environment in order to deliver not just output but outcome and to avoid falling into mere status reporting is what I’ll demonstrate in this blog post.

Most software teams that work in iterations use some form of task board. These boards consist of several columns representing the current status of a task. In the simplest case, three columns TODO, DOING, and DONE are sufficient. Depending on the project setup, additional columns may appear at the beginning for design and refinement phases. On the other end, columns for testing or approval by the product owner or other stakeholders can be added. Furthermore, it is possible to assign each item on the board to the person currently working on the corresponding task.

Task Board with 3 Columns

Shared Ownership

The entire team is responsible for completing the work items. Therefore, user stories (or bugs or issues) are not assigned to individual people. At the beginning of an iteration, the team commits to a workload it believes it can handle. When a new work item is started, it is broken down into concrete tasks that need to be completed. During implementation, additional tasks may be added as it becomes clear that further work is required. These sub-tasks are then handled by individual team members and assigned to them on the board. In this way, multiple people can work on the same user story in parallel, allowing the team to keep track of which tasks are in progress and how many people are involved in each.

Shared Ownership Board

This means that everyone on the team is responsible for completing the currently active work items. Throughout the entire process, there are no “my” or “your” stories. Once someone has finished their current task, they can join another story already in progress. Only when no further parallel work is reasonably possible does the team begin implementing a new story.

Prioritize

How do I decide which task to tackle next? Because of the shared ownership of the entire iteration scope, I don’t have “my own” stories to work through. To avoid starting the next story at random, it’s important to prioritize the work currently represented on the board. Stories located further to the right side on the board are more important than those on the left. They always have a higher priority. If a story is in the TESTING column, I pick it up and test it. Instead of having a dedicated TESTING column, you can also simply create a sub-task for testing on the board. If a story is in the DOING column, I contribute to that story. Only when there are no more stories remaining on the right side of the board and no parallel work on active stories is possible does the team begin working on a new task.

In the Kanban framework, this concept is known as the Work in Progress (WIP) Limit.

The reasoning behind this approach is simple: user stories that are not finished — that is, not in the DONE status — provide no value to the product. One completed story is more valuable than five that are only partially done. After all, “almost finished” is not “finished”.

Stop Starting, Start Finishing

Walk the Board

As we’ve seen above, we walk through our task board from the right to the left and the same principle applies to our daily sync meetings with the product owner. We go through the board from right to left, clarifying which items have been completed and can be accepted. It’s sufficient for one person to guide the discussion through the board; there’s no need for everyone to report on their individual activities. The purpose is not to justify how one spent the previous workday or to showcase progress on a personal story. When issues arise, the team discusses them collectively to find a solution.

By following this approach, teams can maintain focus even in stressful situations and ensure the continuous improvement and evolution of the product.