Your Backlog Might Be Broken If…(Part 2)

Poor backlog management yields inefficient and ineffective projects. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn, and value will be lost.  Successful organizations give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve but the overall goals and objectives are clear, the process is transparent and teams gain efficiency.

Strong backlog management practices:

• Keep teams focused
• Deliver value quickly
• Inspire innovation and creativity

It can be quite difficult for organizations to objectively assess the health of their backlog management processes and even more difficult to implement changes.

In Part 1, I wrote about prioritization and inside-out backlogs.

In Part 2, we continue our journey by highlighting a few more characteristics of broken backlogs.

YOUR BACKLOG MIGHT BE BROKEN IF…THERE ISN’T A GUARD DOG.

Who builds, prioritizes and monitors the backlog? Is it a business analyst, project sponsor, product owner, project manager, development team manager or scrum master? Honestly, the mindset matters so much more than the title! The team can even manage the backlog together, as long as there is a clear decision maker.

Is anyone able to just throw something on the backlog? If so, do you have a guard dog that determines it’s priority, relevance and value? This person needs:

• Knowledge of organizational strategy, goals and objectives
• Understanding of feasibility and rough cost of features
• Knowledge of stakeholder needs
• Knowledge of end user needs and priorities
• Authority to make decisions
• Authority to modify the backlog

The guard dog should be vocal throughout the project lifecycle and shepherd team members to solution value. They need to advocate for organizational value and end users while helping team members understand how project decisions impact various domains, solutions, users, and the organization as a whole.

YOUR BACKLOG MIGHT BE BROKEN IF…THERE ARE MULTIPLE BACKLOGS.

Successful project teams put ALL of their incoming work into ONE queue. You can’t effectively manage priorities, time, cost and resources if there are multiple backlogs.

If you maintain multiple backlogs, how do you decide which work is most important? How do you clearly communicate priorities to the project team? How do you get the team focused on the most important stuff? Multiple backlogs create confusion and teams easily loose focus as they try to manage and work on multiple things at once.

If you value focus and efficiency, don’t derail the team’s work with competing incoming pipelines. Build one queue!

YOUR BACKLOG MIGHT BE BROKEN IF…THERE IS TOO MUCH DETAIL.

Even if you do have a single backlog, it still might be broken! We need to address the idea that a single backlog of 100s of items is ridiculous to mange and prioritize. So, what gives?

Well, the backlog needs progressive decomposition! What does this mean? It means that items, as they are put on the backlog, and if not prioritized at the top, go into a larger category or larger feature. So, the further back in the priority, the larger, more ambiguous, more conceptual the item or feature is. This helps teams continue to see the big picture and prioritize based on value without managing 100s of items.

The backlog should not be a detailed requirements document! Only the items coming up in the next couple of iterations need detail. The other items can be loose categories and higher level items until they are prioritized to the top of the list. Once prioritized, we can decompose them to the point that they are estimable into a sprint.

For example: A backlog item may say something like, “Add the shipping amount to the cart total when customers view their cart totals while shopping.” Once this is prioritized, and the team determines that this is too big for an iteration or sprint, we can decompose it into further detail to multiple items like:

• For US shipping purchases and USPS shipping method, add the shipping amount to the cart total when customers view their cart totals while shopping.
• For US shipping purchases and other shipping methods (FedEx, UPS), add the shipping amount to the cart total when customers view their cart totals while shopping.
• For FedEx global purchases outside the US, add the shipping amount to the cart total when customers view their cart totals while shopping.
• And so on…..

The team can again assess the estimates to complete these newer decomposed items and determine how much can fit into a sprint/iteration, de-scope, update priorities, etc.

Your backlog items only need enough detail to define the user goal and help the team prioritize the work. Don’t worry about the details until the item approaches the top of the backlog or until it has been assigned to be developed. On many agile teams the further details of the story get worked out once the sprint starts with the team through experimentation, prototyping, and conversation and feedback loops.

This strategy will minimize rework and the need for detailed change control while the project evolves.

YOUR BACKLOG MIGHT BE BROKEN IF…THERE IS NOT ENOUGH DETAIL.

Does your team ever have features or stories that don’t get done in an iteration or sprint? It might be because the backlog did not have enough detail. Your backlog items should be more detailed as they climb in priority and get closer to entering a sprint.

However, many teams struggle to define “detail.” In this case, detail is enough information to allow the team to commit to getting the item done in the time allowed (i.e., a single sprint). If the team talks about the item and does not think it can be completed, it needs to be sliced further. Slicing further does not mean dividing it up into tasks, components, or technical design details! Instead, slice by decomposing the item into smaller, but still user-valued pieces, without getting into technical design details or team tasks.

Need a few slicing strategies that will help you avoid tasks and technical design? Try:

• Process sub-steps
• Scenarios
• Business rules
• State changes
• Personas
• User roles
• Exceptions

Rephrasing can also help teams hone in on value. For example: An item that says, “upgrade the server” could be rephrased as “in order to use the new ‘profile update’ functionality, we need to upgrade the abc application to the latest version.”

Backlog items should not require multiple iterations to complete. SLICE THEM and DICE THEM, but make sure you break needs and features into distinct, logical, user-focused chunks of work. Getting backlog items to the right level of detail simplifies requirements, development and testing processes.

IS YOUR BACKLOG BROKEN?

So, let’s go back to the beginning—are you building and managing your backlog strategically or simply building a to-do list without much thought?