While backlogs sometimes appear to just be business as usual, excessively large backlogs can cause several issues for teams, including:
Communication Complexity: Increasing team size exponentially amplifies communication channels, risking miscommunications, inefficiencies in information sharing, and even communication breakdowns. Information overload from excessively large backlogs can cause stakeholders to miss crucial details, undermining the Agile emphasis on effective communication.
Loss of Focus and Clarity: An extensive backlog overwhelms team members, obscuring priority items and causing confusion that can hamper productivity.
Prioritization Challenges: The daunting size of a backlog makes it more difficult to identify critical features, causing important elements to be overshadowed by less essential ones.
Increased Technical Debt: Items remaining in the backlog too long can become obsolete, necessitating substantial rework, and contributing to technical debt.
Demoralization of the Team: A perpetual backlog is demotivating, leading to stagnation, reduced morale, and increased risk of burnout.
Difficulty Planning Sprints: Bloated backlogs hinder effective Sprint planning due to the excessive time needed to sort through numerous tasks.
Impeded Feedback and Adaptability: The agility principle of rapid response to feedback is compromised as large backlogs delay necessary adaptations.
Resource Management Issues: Excessively large backlogs muddle resource allocation predictions, possibly leading to budgetary excesses and resource wastage.
Definitions:
Product Backlog: The product backlog is a prioritized list of features, changes, enhancements, and fixes that need to be made in the product. It includes everything that could possibly be needed for the product and is the single source of requirements for any pending product changes. The Product Owner is primarily responsible for the product backlog, with regular input and updates from the entire team.
- Characteristics:
It is dynamic and subject to change, evolving as the product and the product environment evolve.
It contains a list of all desired work on the project and is the primary input for Sprint Planning.
Items on the product backlog are ordered based on their priority, and this prioritization is a key responsibility of the Product Owner.
Each item in the backlog should be expressed clearly and concisely and should provide tangible value once completed.
Sprint Backlog: The Sprint backlog is a subset of the product backlog, representing the specific tasks to be completed during a Sprint (the short, regular work cycles Agile teams operate in). It includes a list of items selected from the product backlog for the Sprint, along with a plan for delivering the product increment and realizing the Sprint Goal.
- Characteristics:
It is a commitment made by the development team to implement a set of features from the product backlog during a specific Sprint.
It is more detailed and granular, with each item on the Sprint backlog broken down into tasks expected to be completed by the end of the Sprint.
The development team manages the Sprint backlog, and only they can change it during a Sprint.
It serves as a plan and set of guidelines that the development team follows during the Sprint, providing a clear understanding of the work that needs to be done.
Grooming: The process of backlog grooming typically involves:
Detailing User Stories or Tasks: Initially, many items in the backlog are broadly defined. During grooming sessions, these items are broken down into more detailed user stories or tasks. This detail helps the team understand the scope of work and can estimate the effort needed more accurately.
Estimation: The team discusses the effort required to complete each item in the backlog. They may use story points, ideal days, or other estimation techniques to assess how much work is involved and how complex the item is.
Prioritization: The Product Owner, with input from the team and stakeholders, prioritizes the backlog items. This prioritization is based on factors like business value, customer urgency, dependency, and risk. The most critical and high-value items are typically placed at the top of the product backlog, indicating that the team should work on them in upcoming Sprints.
Removal of Outdated Items: Some backlog items may become obsolete or irrelevant as the project progresses. These items are identified and removed during grooming sessions.
Acceptance Criteria Review: The team reviews or adds acceptance criteria to ensure the requirements are clear. This criteria serves as the “definition of done,” helping team members understand what must be accomplished to consider an item completed.
Discussion of Technical Considerations: Sometimes, particular technical aspects need to be considered before work can begin on backlog items. These might involve technical constraints, architectural changes, or dependencies on a different product team or third-party software that need to be addressed.
Preparation for Sprint Planning: Through grooming, the team ensures the highest-priority items in the product backlog are sufficiently well-defined, estimated, and ready for the next Sprint planning session.
Backlog grooming usually occurs regularly, often as a scheduled meeting, but it should also be an ongoing process throughout the Sprint.
While it doesn’t need to involve the entire team every time, key participants should include the Product Owner, the Scrum Master, and any team members who can provide valuable insights into the technical feasibility and scope of work.
By keeping the backlog groomed and organized, the team ensures smoother Sprint planning meetings and sets the stage for more efficient, focused work periods.
Going from Suck to Awesome
Suck – Having a backlog that is so massive it doesn’t add any value because finding an individual story within the list is almost impossible. Plus, when you do locate the story, you need to reconfirm its relevancy and accuracy.
Still sucks – Having a backlog that’s so large it takes significant time to find stories.
Sucks a little less – A large backlog that has been groomed and continues to shrink.
Awesome: A well-groomed and manageable backlog.
Managing Excessively Large Backlogs
Ideal Backlog Size (Not Too Small, Not Too Big)
I prefer to have between two and three Sprints worth of stories in the team’s backlog. If the team is on one-week Sprints, I may include three or four Sprints worth of stories. Some Product Owners prefer a little more, but at some point, the additional stories just become noise.
The concept of an “ideal” product backlog in Scrum usually refers to its qualities vs. a specific number of items it contains. Here’s how an ideal product backlog should look:
Refined and Prioritized: The backlog should be well-groomed, with items clearly defined, de-duplicated, and prioritized. The most important tasks are at the top, and items are ordered to maximize value delivery to the customer.
Estimable: Items in the backlog should be small enough that the team can reasonably estimate the effort they require. If an item is too large, it should be broken down into smaller, more manageable tasks.
Flexible: While the high-priority items are more defined and clearer, the lower in the backlog you go, the less refined the items should be. This approach accommodates market or business strategy changes, allowing for new insights and priorities.
Sustainable: The backlog should reflect the team’s capacity, considering their velocity from previous Sprints. It shouldn’t be so large that it becomes impossible to imagine ever completing it, nor so small that the team risks running out of tasks.
Reviewed Regularly: To maintain its effectiveness, the product backlog should be reviewed and updated regularly to remove items that are no longer relevant, adjust priorities, and add new requirements when discovered.
Comprehensible: Anyone looking at the product backlog should be able to understand the items on it. If it’s too technical or filled with jargon, it risks misinterpretation or incorrect prioritization.
Agile Coach or Product Owner Radical Approach for Reducing the Size of the Backlog
It’s simple: Find the top 50 stories and delete the rest—seriously. I have used this approach before, and you wouldn’t believe how liberating it is. Keep the top 50 stories and delete the rest. Initially, you will probably hear all sorts of arguments for not taking this approach.
Here are some of the more common concerns I hear voiced:
Complaint: “We can’t delete all those stories; it took years to enter all the information!”
Response: “So, you’re saying some of those stories were entered over a year ago? Is it possible that they are out of date? Won’t it be a lot of work trying to figure out which stories have to be updated and which stories don’t?”
Complaint: “If we delete all those stories, the stakeholders are going to be angry!”
Response: “Do you think we could make the stakeholders happier if we could get more work done faster? AND be able to more accurately predict how long it’s going to take to get the work done?”
Complaint: “What happens if those old projects become important sometime in the future?”
Response: “If they do, we can get requirements from the new stakeholders, taking into consideration the new constraints and direction of the business.”
Team Approach for Reducing the Size of the Backlog – My Top 10
Let each member select up to 10 stories they would like to keep. Advanced teams probably don’t assign tickets until the work begins, but some teams select which users will work on stories ahead of time. It is more common to pre-assign stories when the skills within the team are unique, as would be the case if there was only one developer.
Any story that at least one team member hasn’t selected should be deleted. With an 8-person team, you will end up with about 75 stories. If 75 stories are typically completed in one or two Sprints, then increase the number of stories each person selects to 15.
Team Approach for Reducing the Size of the Backlog – Any Top 10
This approach is almost the same as “My Top 10” but without the constraint of selecting only your own stories. In this variation, members can keep any stories, regardless of whether they might work on them.
Team Approach for Reducing the Size of the Backlog – Bottom 10
As part of the planning ceremony, team members pick 10 stories to delete each Sprint. If your backlog has thousands of stories, have each person pick 10, and have the list ready before the planning meeting.
This approach is good for teams that have commitment issues. It isn’t that much of a commitment to delete stories everyone knows will never be worked on. As the list gets smaller and smaller, it may require additional conversations to determine which stories to delete. If the team is taking too long, time-box the exercise. If the backlog is being aggressively groomed each week, then at some point, the backlog will be in good shape.
Tip: Most Agile software systems now support some sort of tagging. Each person can have their own delete tag, for example, “Lexi-Delete.” This way, each person can quickly show and confirm with the group which stories they chose. If you have an eight-person team, 75 or more stories can be removed each Sprint.
Start Over
If any of the following are true, then a simpler approach is to delete all stories in the backlog.
The other approaches sound like a lot of work.
The quality of the stories is very low.
The business has pivoted, and existing stories don’t reflect the new direction of the company.
If this approach sounds appealing but the team is nervous, you could easily archive or hide all the stories. This way, they are still there if you need them. My guess is that shortly after you archive the stories, nobody will ever go back to try and find something.
Be mindful of when the entire backlog is deleted because the team will need something to work on when their current Sprint ends. It might be better to preplan one Sprint and then delete the entire backlog. The Product Owner will have to play catchup for a couple of Sprints, but working on the right stories is much better than feeling overwhelmed while not working on the highest priorities.
5-Minute Move – Move as Many as You Can
Set a 5-minute timer and let the team select any story they would like to keep. If your Agile software supports it, have the whole team participate at the same time. Give each person five minutes to tag any tickets they want to keep.
Five minutes should feel extremely tight; that is the point of the exercise. Create an artificial constraint that forces people to decide.
Delete One Story for Every Story You Complete
Some teams are very methodical; all of their actions are very precise. In these cases, it might be better to have each team member tag a ticket to delete upon completion of each ticket. This approach will take longer than the others, but it can happen asynchronously and without much team effort. This approach won’t take much management. It might also be better for when a backlog has a lot of stories in it that are similar.
Conclusion
In examination of backlogs, the negative repercussions of bloated backlogs include hampered communication, increased difficulty in planning, and prioritization challenges.
To counter these issues, I suggest rigorous grooming of the excessively long backlog, specifically by deleting stories.
Strategies for reducing backlogs range from slowly purging stories each Sprint to more radical approaches of completely deleting the backlog. These methods aim to enhance focus, improve productivity, and boost team morale.
Hopefully, I have presented a compelling case for a proactive, streamlined approach to backlog management, asserting that such strategies revitalize team workflow and performance and ensure a clear, purpose-driven, and achievable set of goals.
Comments