Don’t worry. It happens to a lot of people. Really, it doesn’t matter.
But deep down, you know it does.
You got ahead of yourself, got way too excited to get it done, and you finished before they even started.
Now you need to start all over again while there are (inwardly) shaking their heads and tutting.
Learn through experience
When you feel the shame of an over-estimated Product Backlog, you should try and learn from your experience.
- Look to find where things went wrong.
- Slow yourself down.
- Focus on only the immediate next thing.
- Don’t get ahead of yourself, and definitely don’t try and get everything done at once.
- Avoid the ‘quick fix’ pill
- Practice to improve through better technique
Conquer molehills, not mountains
Product Owners, Business Analysts and Team Members can find themselves in a situation where the WHOLE Product Backlog has been broken down into such granular detail that it is difficult to see the simplest path to maximum value.
When coaching teams on preparing Product Backlogs and Sprint Backlogs, the importance is focussing on ‘the work not done’.
It is far too easy to start breaking down everything in the Product Backlog before you get started, and some self-control is needed.
When you start to groom refine your requirements, making sure that the focus is on the highest priority item that will deliver the most value (cash, time, satisfaction, legal, etc.) to the customer is imperative to building the right thing.
Cone of Uncertainty
Agile embraces change like a warm blanket. We not only expect it but welcome it with open arms. But you have to enable for change to happen, or madness that way lies.
Hurricane Catrina Forecast August 25th 2005 from Weather.com
When forecasting hurricanes, meteorologists use forecasting models based on huge amounts of data categorised broadly:
- Current (location, windspeed, direction, etc)
- Historical (previous paths, global air streams, time of year, etc)
They use huge amounts of data to build models that help predict the future path of a hurricane.
The problem in the modelling comes from the certainty of the data.
Historical data doesn’t change. Current data does.
The models are constantly updated and so the forecast into the immediate future is pretty accurate.
But try and map out where the hurricane lands in 1 day. 2 days. A week.
The further out the forecasting, the more uncertain the planning becomes and this increase in the size of variance of the forecast is known as the cone of uncertainty.
Apply this mental model to your Product Backlog.
If you break down every last Feature into Epics and Stories and Tasks (before you even know what the priority is) you will end up with a huge mountain of requirements which seems unsurmountable.
It also is likely to change.
A lot.
The market may shift. Mobile may no longer be what your customers want. A corporate rebrand means that all the colours and fonts need to change.
If you have hundreds of items to look at, it will take the whole team a long time to rework each one of these. Or worse, discount them altogether.
Confusion ensues, priorities get misunderstood, work completed is discarded, and morale drops. Not conducive to a shared understanding or building great things…
Iceberg! Dead ahead!
Luckily there are techniques that Product Owners can use to help prioritise the next best thing to work on (Story Mapping, WSJF, MoSCoW, Business Value, Kano, Cynefin, etc.).
Whichever is used to prioritise, it is important to look at how you decompose each layer of requirement.
It is easiest to picture the Product Backlog as a huge iceberg with 3 main layers.
- Stories
- Epics
- Features
Stories are small and at the very top of the iceberg, above the waterline. They can be pulled into the Sprint Backlog and delivered in a single Sprint.
Epics are large stories. Far too large to be delivered in a single Sprint and need to be refined and broken down into smaller chunks teams can work on.
Features are very large areas of functionality within the Product. The areas of the Feature breakdown into Epics.
The team should be aiming to breakdown only the most valuable areas of each Feature so that they are working on the most important thing for the customer.
They should also not necessarily aim to complete a full Feature or full Epic before moving onto the next. Within each layer, there will be priories – some things will be required and others ‘nice to have’.
The Product Owner’s job is to filter these requirements based on the current priority.
Refining only a few sprints ahead will provide greater agility for the team to move, discount, introduce or change backlog items easily.
If the entire Product Backlog is already completely broken down, this becomes very, very hard to do.
Slow down to speed up
So, the next time you are tempted to jump in and get things done quickly, remember to slow down and focus on the next most important thing first.
It will make things much better for everyone and may even help you last longer as a team.
If you want to become a product owner, visit our Certified Scrum Product Owner course page and Advanced Certified Scrum Product Owner course pages.
If you need support with backlog refinement, prioritisation and estimation, get in touch with our team to see how we can help.