In theory, it shouldn’t matter how many statuses your team uses to describe user stories. Or should it? If a story goes through eight different user story statuses from conception to completion, then the story most likely goes through eight different queues. (Some teams allow for stories to skip statuses, but this is less common than you would think.)
Decades of research in the physical world have provided some historical reference on how statuses can impact your team. Statuses are really queues by a different name. The theory of constraints (or TOC) was introduced by Dr. Eliyahu M. Goldratt in 1984 in his book The Goal.
Here are some downsides to queues:
Increased Complexity: Managing multiple queues adds complexity to the system. It becomes challenging to prioritize tasks across different queues, and the coordination required to keep all queues balanced can be overwhelming. This complexity can lead to inefficiencies and errors in task management.
Longer Lead Times: With multiple queues, tasks can get stuck in different stages, waiting for attention. This fragmentation can lead to longer overall lead times, as work in one queue might be delayed while waiting for input or output from another queue.
Higher Costs: Multiple queues often mean more work-in-process (WIP), which ties up resources and increases operational costs. Each queue requires monitoring and management, leading to higher administrative overhead and potential waste.
Hidden Bottlenecks: Multiple queues can make it difficult to identify the true bottleneck in the system. Issues in one queue might be masked by activity in another, obscuring the root cause of delays and inefficiencies.
Resource Inefficiency: Managing multiple queues can lead to inefficient use of resources. Teams might experience idle time if they are waiting for tasks from another queue to be completed, leading to suboptimal use of available capacity.
Consolidating and minimizing the number of queues software development teams use can enhance throughput, reduce costs, and improve overall system performance.
Definitions:
Queues: Individual statuses of user stories (tickets). Each status creates a queue. Typically, stories move from one status to another in a defined linear approach if stories don’t skip statuses. Statuses are normally represented as swim lanes, but stories usually reside in the backlog, which is a type of status.
Swim lanes: All stories are visually represented in “lanes” or columns, so it’s easier for the team to know how they are progressing with their work.
WIP (Work in Process): See Rolling User Stories for the full definition.
TOC (Theory of Constraints): TOC is a management philosophy aimed at helping organizations achieve their goals by identifying and managing the most critical limiting factor, or constraint, that stands in the way of achieving higher performance. The underlying principle of TOC is that every system, no matter how complex, has at least one constraint that limits its ability to achieve more of its goal. By focusing on this constraint, an organization can improve its overall performance. The Theory of Constraints was developed by Dr. Eliyahu M. Goldratt, an Israeli physicist turned management guru, in the early 1980s. Goldratt introduced the concepts of TOC in his seminal book, The Goal, published in 1984.
Going from Suck to Awesome
Sucks – Way too many lanes.
Sucks a little less – Reasonable number of lanes but with no clear reason why any lane exists. It isn’t great when lanes are a mix of different types. For example, to-do, doing, and done are logical progressions, but to-do, move back for clarification, In progress, needs a 2nd approval, done, failed after done, and then production may be valid conditions within a story but are noncongruent.
Awesome – As few as possible lanes to effectively communicate user story statuses.
Determining the Right User Story Statuses
Typical Starting Points
Teams oscillate between too few swim lanes and too many. This is where legacy practices keep reappearing. A couple of general guidelines: As I write this, most tools are web-based and, therefore, work much better without horizontal scrolling. So, rule 1 is: If you have so many lanes you have to horizontally scroll, you have too many lanes. I once worked with a team that had 17 lanes. No joke.
Ideal Number of Lanes
The minimalist will have three lanes: to-do, doing, done, and in fact, that is the default setting on most tools. BUT once the team starts working, they start adding more lanes. For example, a common lane added is ready for QA, which then leads to another lane called “QA completed.”
When you consider why a status (lane) should exist, a couple of common patterns appear. Lanes are usually required when work needs to switch from one person to another. The reason the work needs to be passed between people could be that your team has dedicated quality roles, or maybe everyone is a developer. But you require a second, different person to double-check the work completed by a developer.
Another reason user story statuses exist is because your process has an intentional or unintentional gate. An obvious example would be deploying to production. Maybe stories need to be grouped for deployment within a Sprint because your systems don’t allow the deployment of individual stories.
I would suggest between three and seven lanes. Teams start small, then keep adding, and then, at some point, teams start removing lanes until they settle in. Try avoiding adding lanes for every little discrete step. It is beyond the scope of this blog, but each lane will actually create drag because queues create latency. By creating a swim lane, you are saying, I want this work to “wait” in this status, so it is visible in this state until somebody can act on it. Unfortunately, each lane will reduce your velocity. Some wait states will be required, but the idea is to reduce the amount of wait time so work can “flow” through the system.
When a story is in the backlog, that is a type of synthetic status. Some tools allow for stories to be in the backlog but also have a status. This is awkward and should be discouraged. If a story is “In Progress,” it should be in the current Sprint, not in the backlog. Usually, what happens is it has been removed from a Sprint, likely in the past, and was never put back into a “backlog” status. With few exceptions, stories in the backlog should all have the same status.
Some tools support long-term planning and have a long-term backlog. These are stories that are being organized and aren’t quite ready for the team to see. Again, these stories have a synthetic status of “Long-term backlog” or “Not quite ready to plan.”
Most teams start with four statuses: “To-do,” “In Progress,” “Done,” and “Backlog,” with the potential of adding a “Not yet ready to plan” status as their backlog grows.
Additional Optimizations
The first optimization that should be applied to any board is having a board. There are dozens of tools available to manage projects. Most of them boast of their “Agileness,” but in my experience, most are actually old-school project management tools. If you aren’t using a common Agile tool such as Jira (by Atlassian), you should configure your system to support the following:
o Sprints
o Estimates in points
o A visual to show only the work currently in the Sprint divided into lanes or columns
o Easily visually shift work from one status (lane) to another
o Link work, which is the ability to group like stories under a single topic (Epics) and the ability to have several components to a story (tasks and sub-tasks)
o Assign work to an individual
o A method to indicate a ticket is blocked
I have become more aggravated by tools being shoehorned into an organization that can’t perform the above. Now, as part of my consulting, I always investigate why my client chose a tool, who uses it, and what the motivation was. Many times, there was no rhyme or reason, so the tools can be swapped out.
Automate common tasks. If your team uses tasks within a story and individual tasks are all closed, why make a human close the parent task? Create automations that close stories. If your team keeps track of stories that are open too long, automation can automatically alert the appropriate people. If your team is advanced, story status can automatically deploy completed work to production.
Modify the story structure to match your teams’ specific needs. Many tools allow for the definition of stories at the field level. Every industry has nuances, and those should be represented in your stories.
Modify the flow of stories. Once again, every team and industry is different. If a single linear progression isn’t enough, modify your workflow to represent how stories flow between statuses. Permissions and automations can be wired into the flow to help the flow of information. For example, if the developer wants to know if QA has rejected their story, an automation can be set up to notify them.
Add filters—filter by name, status, etc.
Conclusion
The small details can make a big difference in your team’s velocity. Leveraging decades of research and best practices can remove friction from your team.
Some items are bigger than others. For example, using the wrong tool can have a large impact. Keep evolving. As teams change, so should their relationship with the board. At some point, the team will settle into a pattern, but change is good if it leads to a more optimal state. Experiment with how your board is set up.
By consolidating and minimizing the number of queues, software development teams can enhance throughput, reduce costs, and improve overall system performance. This process of continuous improvement and adaptation ensures that your team remains agile, responsive, and efficient in the ever-evolving landscape of software development.
Comments