The Flaws of Using Sub-Tasks to Organize Work in Agile Software Development and Why Moving Stories is the Key to Success
Agile software development is a methodology that emphasizes teamwork, flexibility, and continuous improvement. A key component of this approach is the use of a Kanban board to manage work and visualise progress. However, some teams organise their kanban board incorrectly, which can lead to confusion and inefficiency. In this article, we will explore why this flawed approach is problematic and why moving stories across the board is the correct way to organise work.
First, let’s define some terms. In agile software development, a story is a high-level description of a user’s needs. It represents the value that the customer expects to receive from the software. A sub-task, on the other hand, is a specific piece of work that needs to be completed to deliver the story. Sub-tasks are usually related to a particular aspect of software development, such as development, testing, or deployment. A workflow, or value stream, is the sequence of steps that a team follows to deliver software.
Now, let’s consider the flawed approach that some teams take. They define their workflow as To Do, Doing, Done, and use stories for swimlanes, moving sub-tasks across the board. This means that each story has its own row or swimlane on the kanban board, and the sub-tasks are moved across the columns as they are completed. However, this approach is flawed for several reasons.
First, it can be confusing and difficult to understand. When sub-tasks are used to represent work on the kanban board, it can be challenging to see the big picture of what is being accomplished. This can make it hard to track progress, identify bottlenecks, and make informed decisions.
Second, it can be inefficient. Moving sub-tasks across the board can create a lot of unnecessary work and communication. When a sub-task is moved from one column to another, you are operating in a silo’d nature. This can slow down the development process and lead to delays.
Finally, this approach can lead to a focus on tasks rather than value. When sub-tasks are used as the primary unit of work, it can be easy to lose sight of the value that the software is intended to provide to the customer. This can result in a product that is technically excellent but does not meet the needs of the customer.
So, what is the correct way to organise work on a kanban board? The answer is to move stories across the board rather than sub-tasks. Stories represent the value that the customer expects to receive from the software, and they should be the primary unit of work on the kanban board. When a story is completed, it should be moved across the columns of the workflow, from left to right. This approach has several benefits.
First, it provides a clear and intuitive way to visualise progress. When stories are moved across the board, it is easy to see what work has been completed and what is still in progress. This can help the team to identify bottlenecks and make informed decisions.
Second, it can increase efficiency. When stories are used as the primary unit of work, collaboration between team members can be maximised. This can speed up the development process and reduce delays.
Finally, it ensures that the team remains focused on delivering value to the customer. By using stories as the primary unit of work, the team is constantly reminded of the customer’s needs and the value that the software is intended to provide.
In conclusion, the kanban board is a vital tool in agile software development, and it is essential to use it correctly. Using stories as the primary unit of work on the kanban board and moving them across the workflow columns is the correct way to organise work. This approach provides clarity, efficiency, and a focus on delivering value to the customer. Teams that adopt this approach will be better equipped to deliver high-quality solutions that meet the needs of their users.
