This is the first question you have to ask a team you coach
How DEEP is your Product Backlog?
When I coach a team to help it to raise its productivity, I always start with an audit of its Product Backlog. Why? Because everything starts with project requirements and the product backlog contains all of them. How to assess a team’s Product Backlog?
* * * * *
I recently wrote an article that shares my tips for gaining predictability in an Agile environment. One of my tips, and probably the most important one, is to take care of your Product Backlog.
Why the good shape of your Product Backlog is the most important thing you have to do for a smooth process and predictable project deliveries?
When I coach a team to help it to raise its productivity and to open its eyes to the mistakes in its way of working, I always start with an audit of its Product Backlog. Why? Because this is the primary tool for planning in Agile. Not by accident, it is the artifact at the start of the Scrum diagram. Everything in a project starts with a list of requirements. In Agile projects, this list is in the product backlog. It contains all the work that needs to be done and is known at this time.
What exactly do I audit?
I just ask them how DEEP is your product backlog.
…And I get this answer:
Joking :)
I ask the team to show me its product backlog, and I ask a few questions to assess if and to what extent it is DEEP.
What does it mean to have a DEEP product backlog?
I like abbreviations because they help us remember something easily. The thing I don’t like is that most people don’t understand the meaning behind each item. The DEEP product backlog means.
Let’s shed some light on the meaning of each item.
Detailed appropriately
It means the right level of detail of product backlog items. If your team is going to implement something after four months, it is probably not worth spending much time defining it in detail now. And vice versa — if they are going to pull an item for the next sprint and there are still many unknowns-this is a problem.
Usually, I get the question: what is the meaning of adding something to the backlog if there are many unknowns? This simply increases transparency which is vital for an Agile environment. If it stays somewhere in a personal product owner’s list, it will not help anyone, and there is no chance of raising discussion and asking questions about this item.
I will not forget a product owner of a team I coached. How surprised she was when I told her that she doesn’t have to describe everything that is added to the backlog in detail! She kept items separately in her private backlog until all details were precise. She felt overwhelmed all the time, and she couldn’t manage her time effectively since she was spending much time on items that were not a priority for the team right now.
Estimated
All items in your product backlog should be estimated.
The next logical question is — how can the team estimate something since there are items with so many unknowns? This is why Agile teams use the Fibonacci sequence (or variation) when they provide estimates.
The items that are big and/or with many unknowns are estimated with numbers on the right side of the line. For example, when the team gives 20, this might be everything between 14 and nearly 30. When the item is broken down into smaller items and new information appears, the new items will be reestimated with the numbers on the left side of the sequence where the gap between options is tiny. (stay tuned for my next article, where I explain in detail the meaning behind using the Fibonacci sequence)
Emergent
You and your team operate in an Agile environment. The change is inevitable, and your product backlog should reflect these changes. Sometimes teams are afraid to change the product backlog because this will affect the plan too, and they will not be able to meet the deadline. It doesn’t change the fact that the change is there and has to be handled. Sometimes it is just easier to handle something bypassing the product backlog. Your product backlog is a live artifact and should reflect the constant change in the external environment. Usually, I can assess this parameter after two-three sprints of observing and working with the team.
Prioritized
As the product backlog is a list, it is always prioritized. Regarding this attribute of the product backlog, I assess the quality of the set priorities. Are they reflect reality? If I am a stakeholder who wants to know more about the team’s work and I open the PB, will I see a mirror of the current situation? If I am a team member and I have to pull an item from the backlog, do I have to ask before that which item to start working on? If the answer is yes, it is a clear sign of fake priorities.
There are many benefits to keeping your product backlog in good shape. It is the main planning tool in an Agile environment and helps increase predictability, establish transparency, create shared understanding, and develop smooth processes.
My next article is going to explain in detail the meaning behind using the Fibonacci sequence.
If you have liked the above article, click on 👏 and follow Teodora Todorova for more such articles.
