The success or failure of agile projects, such as those implementing the Scrum delivery framework, is often directly related to the quality of estimation applied to the product backlog during release planning. This post provides an outline of product backlog estimation concepts and techniques.
By way of introduction, the product backlog on an agile project contains a prioritised list of user stories in business value order. The level of detail, or clarification, for each user story should align to the priority; higher priority equals more detail. A Product Owner manages the product backlog, refining stories through additional clarification, performing (re)prioritisation and ultimately ensuring the content is inspected and adapted to reflect the current state on an ongoing basis. Agile projects will be focused on delivering working product increments on an iterative basis, the product backlog is the source from which the requirements (users stories) are drawn per iteration (sprint). Each product backlog item is estimated in broad terms to help in the planning stage of each iteration, inaccurate or inconsistent estimation can have a major impact on productivity and team confidence.
A primary principle to underline at this stage is that estimated size should always drive duration; a calculated project size and productivity metric should drive the project duration. Duration is always derived. The project size can be approximated using any unit-of-estimation; story points or ideal time. Whichever unit is applied, historical productivity averages should be recorded. From this point the derivation of duration becomes straightforward maths.
Units of Estimation
Agile projects will typically use either ideal time or story point units when estimating. The former is defined as actual productive working time and is simpler to work with than elapsed time which must consider many unknown factors such as administrative overhead that impact upon time on task. The latter uses an arbitrary relative scale (often based on the Fibonacci Sequence) which considers the complexity, uncertainty and risk aspects to a product backlog item. Note, estimation during iteration (sprint) planning always uses time (hours typically) as the unit of estimation. For ideal time estimation the driving factor for calculating duration is the available ideal time per-day, an average must be determined. For story point estimation real data must be collected to empirically calculate the time per story point metric (average historical velocity), from there duration can be calculated. With either approach product backlog item estimates should improve in accuracy over time, that said the time period considered relevant in this context is typically constrained to the most recent set of sprints – the older the data the lower the value to future work estimation.
Story points can be challenging in respect to adoption, the abstraction takes a conceptual leap for many unfamiliar with the approach, however the relative scaling offers longer term benefits. Ideal time estimates often suffer from misinterpretation, i.e. being understood as elapsed time estimates, but can be more approachable and familiar in the early stages of agile adoption.
Before considering individual estimation techniques it is important to outline some guiding principles applicable to estimation. Firstly always estimate comparatively whenever possible; comparing a new backlog item to existing items can ensure consistency and will help to maintain the integrity of the relative scale. Secondly, always sense check the estimate after a short cooling-off period to ensure a fully objective view. Thirdly, make safe assumptions wherever possible such as the logical order in which work will take place, this type of simplification is necessary to reduce the overhead involved in estimation.
Planning Poker enables a consensus view to be established on the estimate for individual product backlog items in a whole-team setting. Each team member is given a set of cards each representing a possible estimate level on the agreed scale. Once the Product Owner has introduced an item the team members as-one turn-over the card that represents their personal estimate for the story. If all team members agree then the estimate is set, if not then the outliers (in terms of estimate level selected) are asked to substantiate their choice, this is followed by subsequent rounds until consensus is achieved.
Planning Poker works as the estimates provided are agreed by the whole-team not imposed by a sub-set. The collaborative discussion aspect is also proven to improve the quality of the estimation process, insight drawn across all contributors also reduces risk of uncertainty. The simultaneous turning-over of the poker cards across the team prevents the phenomenon of anchoring where personal estimates may be impacted by the group.
Tee Shirt Sizes
Where story points are employed as the unit of estimation it can often be challenging to detach the number system from any concept of time required for delivery. In such cases and to reinforce the abstractness of the approach, numbers are replaced by tee shirt sizes. During collaborative discussion of each product backlog item the team is asked to reach consensus on the appropriate size on the scale, small, medium, large, x-l and so on. Replacing a numeric system, with its undue connotations, with something more approachable and fun and creative can work very well, tee shirt sizes is one example, dog-breeds, car types, food products are others that provide the same value. Behind the scenes the abstracted values will need to be mapped into story point numbers for tracking purposes. For new agile teams the tee shirt size technique offers a good starting point which should ultimately lead to actual story points in due course.