One of the original views of ‘pure’ agile development proposed a model where agile teams would work on a project, delivering stories sprint by sprint, and continuing on that path until the product owner judges that sufficient business value has accumulated to warrant a release.  No deadlines, no release plans, just an ongoing experiment that occasionally surfaces something of value.  How nice would that be!

That approach takes huge courage and/or a bottomless pit of money, and as most organisations tend to fall short in both those categories the reality is that 99% of all agile product related projects are working with a ‘release scope’ or a time boxed deadline. In both of those cases there’s going to be a ‘release backlog’ that will need to be defined and curated over the life of the release.  For a scope driven ‘release’ the primary question is about ‘when?’, and for a time boxed project the primary interest is in ‘what?’.   Either way to provide insight on those questions will require that all items on the release backlog have work effort estimates, irrespective of how vague or sketchy the user story details.

As most software folk are extremely nervous about providing estimates/forecasts it’s really important to understand why organisations seek this information.  The primary driver is that there will be one or more downstream actors (e.g. product marketing, customers,  another team) who have a dependency or vested interest on what and when the agile team is delivering,  Planning and estimating is important because its unlikely that this is the only thing that these downstream actors have to worry about,  and they have to schedule handling this release amongst there many other priorities.

This places a release planning curation role on the agile product owner and scrum master to ensure that this information is provided initially and then updated throughout the release time frame.  Work estimation is hard, but the key thing to understand is that estimating an imperfect art exercised against an imperfect information model.

It’s just like baking cookies.  If you haven’t baked before then your first attempt is going to the exercise of an imperfect art with imperfect information.


Even with experienced bakers,  a new recipe might take several attempts before you get perfect results. It’s the same challenge when its comes to estimating and prioritising a release backlog.

When making the initial assessment each release backlog item needs to be reviewed to determine the following factors:

  • Apply a work effort estimate to the item – whether you are using story points or real time – some gauge of effort needs to set.  This is often where the assessors get bogged down. Don’t!   Spend no more than a couple of minutes on each item and make your best guess on the information to hand.  Estimates are often labelled as ‘SWAG’ numbers –  Scientific Wild Arse Guesses.
  • List any major assumptions or unknowns
  • Apply a confidence rating on that estimate (Very high/High/Medium/Low).  This is about quantifying the accuracy of the work effort estimate.  An item with a ‘Very high’ rating suggests that estimate is sound because the problem is either trivial or very well understood; whilst a rating of ‘Low’ is the complete reverse.
  • Identify any external factors or events might trigger a change in this assessment

Keep all these details recorded with the backlog item, so that they can be reviewed and updated throughout the release time frame.

For each item the confidence rating can be used to generate a very simple risk adjusted view of work effort.


The spreadsheet mock-up shown above illustrates how this can be applied. Each release backlog item attracts an initial work effort estimate which is then grossed up based upon the ‘confidence’ rating, e.g. an item with a ‘medium’ rating is inflated by 30%  (100% minus the medium rating of 70%).   My suggestion is to apply the risk adjusted work effort estimates to the release backlog.

It might take several sweeps through the release backlog to get to a balance of how items are estimated with a SWAG view of relative effort and confidence.  Any release backlog items that attract a ‘Low’ confidence rating should probably have an accompanying  ‘spike’ story added to the backlog, where the purpose of that story is to resolve the unknowns/assumptions.

Once the initial (risk adjusted) view of release backlog is established there is release backlog curating role that needs to be applied regularly throughout the release.   Over time the unknowns in that estimating imperfect information model are gong to resolve themselves, providing an opportunity for more informed estimates to be applied to the remaining release backlog content.  There are four or five points where that curation role is best exercised:

  • Backlog grooming – the primary role of the grooming session is to review priorities to ensure that the backlog top slice is in good shape for the next sprint.  However, this review also provides a good opportunity for the backlog work estimates to be re-examined.
  • End of sprint retrospectives –  this meeting provides a great opportunity for providing insights on how planning assumptions are holding up.  Have stories completed in the sprint delivered new insights on the implementation challenge that mIght impact estimates for other items on the backlog?
  • Project governance reviews – if your organisation has a project review/governance model then it would be wise to review and update backlog item confidence assessments.
  • Completion of an associated ‘spike’ user story.
  • External events materialising.  As part of the item estimating exercise the assessor is asked to list any external events that might influence the estimation viewpoint, and if one such event does occur then it needs to trigger an update of the backlog item work estimate/confidence rating.

During a review event the aim to examine all release backlog items, though if release backlog size is large then the review scope  can be constrained to those items with a ‘Medium’ or ‘Low’ estimate confidence rating.  That item level review should cover the following questions:

  • Is the work effort estimate and confidence rating still valid?  Given that there is likely to be more information available now than when the last review was completed,  what new insights can help reduce the estimation risk?
  • Are the assumptions/unknowns still valid?  Resolving these factors will help solidify the item scope, which will again provide greater insight for a more informed view of work effort.
  • Have any of the external events linked to the item changed, expired or matialised?

The first thing to appreciate is that change on estimates is valid and necessary to ensure that realistic release time frames are communicated correctly to down stream actors.

Regrettably most estimate change tends towards delay, but using the approach outlined here the agile team accumulates  a rich set of data points to help improve the agile planning and estimating skills.

In summary…

Traditional views of managing a release backlog have focused on release scope and backlog prioritisation. Whilst those topics remain important, most agile teams miss the equally important aspect of ensuring that backlog item estimates are reviewed and updated as part of that exercise.

That estimating review action should be repeated during the release. Just like when you bake cookies it’s prudent to check the oven during the baking process.  If the cookies are meant to take 25 minutes to cook you could take an optimistic view and wait that period before you  view the outcomes, but all good cooks know that life is never that simple and they will intermittently check progress to avoid burning the cookies.