In traditional ways of working, there is often a significant amount of upfront work spent on analysing the needs and wishes of clients and users in detail. Detailed processes, workflows, screens, reports, and other "necessary" capabilities for users.
People drown in detail, only to detect later that the needs were not as clearly understood or explained as was assumed, and these needs have changed along the way.
78% of study participants indicate that their requirements are usually out of sync with the business. These people surveyed show that shifting requirements are one of the top contributors to failure. So it turns out that detailing requirements upfront is a big waste of team resources.
The concept behind Product Backlog Refinement is to perform just enough "analysis" upfront for the team to understand what an item means and have confidence that they can do the work necessary for this item within one Sprint. All the work implies the development required, verifications, validations, and the analysis and design needed. In this way, the analysis and design take place as close as possible to the implementation, making it possible to consider the latest insights and feedback from clients and users.
Now then, how can we prevent getting into these Drowning Details?
A practice I apply when coaching and facilitating teams with their refinement practices roughly goes as follows:
1/ Introduce the feature (or challenge, or ...) that will be refined in this session.
Typically this is done by the Product Owner, while it is more powerful to have an actual user introducing the item.
2/ Based on this basic understanding, the team sizes ("estimates") this item.
Depending the team's understanding about the current product, the market, the competitors, and how this specific feature fits in, the sizing ranges from huge to small.
3/ Does it fit within one Sprint, together with a number of other similar sized Product Backlog Items?
Based on the past experiences of the team they themselves have a pretty good idea what they can and cannot do in one Sprint.
There are 3 typical answers to this question:
- The team understands the item and it fits in one Sprint. This Product Backlog Item is sufficiently refined. Another item can be tackled if there is still need for it and time.
- The team understands the item but it is too big to be delivered (according to their Definition of Done) in one Sprint. In this situation the next steps the team needs to take is to apply refinement techniques to split this bigger item into smaller ones.
- The team indicates they don't know, because there are still too many unknowns. This indicates the team does not yet understand this item enough. So clarification techniques are needed, which typically also lead to splitting this item in to smaller ones.
4/ Depending the answer to the previous question apply one or more refinement practices, leading to smaller and more precise items.
5/ Back to step 2: size these newly identified smaller items.
These steps involve sizing from the first moment, making the team aware of how much detail they already have or still need. This awareness supports the team not to get into the drowning details of Product Backlog Items.
Now there is this trap... It's the statement coming from team members "But we need to have more details to estimate. Without all these details it is impossible for us to give a good estimate".
This statement shows this team is still used to estimate Product Backlog Items by looking at each of them individually. There are practices though to deal with this. More on that in another blog post.
Summary:
Don't be paralised by too much detail and upfront "analysis" work.
Start sizing Product Backlog Items soon, based on the understanding at that moment. Use these insights to determine if more refinement is needed, and keep sizing these smaller items, until a number of similar sized Product Backlog Items can be delivered in one single Sprint.
Prompt:
Together with your team, have a conversation about how this (or a similar) practice can be introduced in your refinement workshops.
I hope you find value in my blog posts and if you are looking for more clarifications, feel free to take contact.
If you want to take a deeper dive into Product Backlog Management topics, then surely check out our Product Backlog Management Skills workshop. We have some scheduled in the coming period.
Coming up: Sizing Product Backlog Items
