Premature Estimation

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 are feeling 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 the 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, morale drops.  Not conducive to a shared understanding or building great things...

Iceberg! Dead ahead!

Beautiful iceberg photo courtesy of Lisa Stull

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 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'.

It is the job of the Product Owner to filter these requirements based on the current priority.

Refining only a few sprints ahead will actually provide greater agility for the team to move, discount, introduce or change backlog items with ease.

If the entire Product Backlog is already completely broken down,  this becomes very, very hard to do.

Slow down to speed up

So, 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.

------------------------------------------------------------------------------

Jon is an Enterprise Agile Coach with experience of leading transformation programmes and enabling organisations to build award winning global digital products in retail, financial services, marketing and advertising.

Starting out as an Avionics Engineer in the British Army, he now focuses on fixing and building teams (rather than helicopters), empowering them to deliver world-class solutions through iterative, agile methods, lean principles and appropriate use of agile scaling frameworks (Scrum, LeSS, DaD, SAFe).

The views in this post are those of the author and not to be confused as the views of any client or employer.  Image used under Creative Commons license from Flickr: https://www.flickr.com/photos/kalexanderson/6341681338/