Estimation techniques

Estimation techniques2017-10-12T22:05:28+00:00

The principles of Agile estimation

Estimation is as much a basic concern for Agile as for any other lifecycle or methodology.

But the Agile approach to estimating is different:

  • Estimates only need to be precise enough for the team to feel confident enough to proceed.
    • So estimates need to be much more precise when stories are being selected for inclusion in a release than when they are simply interesting ideas being added to the product backlog.
  • ‘Contingency’ and ‘tolerance’ are not required by Agile.
    • Compared to more traditional projects and programmes, the timescales involved in iterations and even releases are very short. So much of the risk and uncertainty that requires contingency and tolerance is absent.
    • If a story cannot be completed because of unexpected factors, the iteration is restructured or the story itself is returned to the backlog and reprioritised.
  • Estimates need to reflect the specific conditions in which the work will be carried out.
    • The factors that need to be taken into account include: the size, complexity & novelty of the system; the skills available to do the work; the difficulty of satisfying the acceptance criteria; the non-functional aspects of the story (performance, reliability, etc.); the team’s ‘Definition of done’.
  • Because of synergies and conflicts between stories, the whole (i.e., the estimate for the release or iteration, or for an epic or a feature) can be more or less than the sum of its parts (i.e., the estimates for individual stories).
  • Estimates are never final.
    • The closer the story comes to being implemented, the more will be known about it.
    • So it is never sensible to ‘finalise’ an estimate.
    • At any point in a story’s lifecycle, from when it first appears as an idea to when it is finally completed, its estimate can be revised.
    • All stories should be re-estimated at least once during the iteration.
  • So any decisions that are based on estimates also have to be flexible.
    • For example, increasing an estimate may make it impossible to deliver the story within the effort available. So it should be returned to the backlog.
  • An estimate should not be allowed to become a commitment. It’s a best guess.
    • Treating estimates as commitments will not make delivery any faster, but it will undermine the estimating process.
  • The estimate should only be as precise as it needs to be to make the decisions it is meant to support.
    • For example, it generally needs less precision to decide whether a story is worth including in a release at all than to prioritise it within an iteration. In that context, a high-level, indicative estimate is generally enough.

Agile has evolved a number of simple estimating techniques, each with their own strengths and weaknesses. A team should expect to use all of them at one time or another.

Story points

The basic unit for Agile estimating is the ‘story point’.

In the standard Agile approach a story point is quite different from, say, a day’s effort. Rather, it is a unit the team themselves define, and it can be different from the ‘story points’ used by other teams. It can even be different from the story points the same team use for another release! This is because the purpose of story points is to create confidence in this team’s current work, which is limited to the current release.

This is how story points work:

  1. The team select a story.
  2. Using one of the techniques identified elsewhere on this page, the team assigns an estimate to the story – say, 2 story points.
  3. But these ‘2 story points’ would not in fact tell an outside observer how big the story is – another team, using exactly the same knowledge and experience, might call it 2 or 5 or any other number of story points.
  4. What matters is that, when you compare all the stories that the individual team estimates, they use the ‘story point’ unit consistently. So within this release a 2-story-point story should always be half as big as a 4-story-point story but twice as big as a 1-story-point story.

In other words, when estimating is in story points rather than absolute effort, the question it is answering is ‘How big is this story, compared to the other stories in this release?’, not ‘Absolutely how much effort will it take the team to complete this story?’ This is because its purpose is not to come up with a number that can be translated directly into some objective measurement (money, hours effort, etc.). Rather, its purpose is to allow the team to get a sense of how large the stories they are going to work on are.

Generally speaking, Agile estimating does not use a linear sequence of numbers – 1, 2, 3, 4, 5, and so on. Because it’s only trying to get a sense of relative size, not an absolute magnitude, it typically uses a geometric sequence such as 1, 2, 4, 8, 16…. The Fibonacci series is also popular.

Likewise, basic arithmetic should apply, but not absolutely precisely. For example:

5 story points + 8 story points 13 story points

is probably good enough!

For practical purposes the maximum number of points that can be assigned to a story is often limited to the series up to 21 or 34. Beyond that, the numbers are too large either to be meaningfully compared to the smaller stories or to be planned for. So it’s useful to include an upper limit that defines ‘too big’. Teams using the Fibonacci series for estimating will often set a maximum story size of 21 or 34. Any story scoring above that should be treated as an epic and should be split into more manageable stories.

So how does the team define the top and bottom ends of the scale of estimates? Here is a simple and effective method:

  • The team review the stories that are currently assigned to the release, and identify what looks like the smallest. Whatever size that is, they call that 1 point.
  • The same process is repeated, this time identifying the largest story they are confident of estimating. This story is given the top value on the team’s scale – 21 or 34 perhaps.
  • All remaining stories are then assigned values on the intervening scale.

This still leaves an important question. If story points have no objective value, how can the team tell when it has ‘filled up’ the iteration or release? This depends on the key measure of the team’s performance, its velocity. A team’s velocity is the number of story points they complete per iteration. So, assuming that they use story points in the same way that they did in the last iteration, they can assume that they will be able to complete the same number of story points in the next. This is how they decide how many stories they can take on in an iteration: it’s the number that add up to (not more than) their velocity.

So here is some general advice for when you are beginning to use story points:

  • Especially when a team is relatively new, it is important that estimates are limited to relative size of stories, as outlined above. Only when the team’s velocity has stabilised and story points can be accurately translated into elapsed time will a more precise type of estimate become realistic.
  • Until then, demanding a precise estimate will be misleading, counter-productive and likely to damage relationships.

This purely ‘relative’ approach to story points has been questioned as unrealistic in a complex organisation, and even as an incoherent concept. However, it is usually best for a team to begin with the standard Agile approach and then, when they have a lot of experience, consider adapting it to their situation.

T-shirt sizing

‘T-shirt sizing’ is an alternative technique that applies some of the core concepts of Agile estimating.

  • The goal is to define the relative size of the stories as a whole, not to define the absolute size of each individual story.
  • Precision is not only difficult in estimating, but it can become very misleading and is often spurious.

Here is how a sizing session works:

  1. All the stories for the session are listed together.
  2. The team then arranges them in order of perceived size.
  3. The stories are then divided into bands:
    1. XS (extra-small).
    2. S (small).
    3. M (medium).
    4. L (large).
    5. XL (extra-large)
    6. XXL (double-extra-large)

This approach has several strengths:

  • It is intuitive.
  • It is easy for a new team to grasp.
  • It can be used to size a large number of stories quickly and in a single pass.
  • It avoids precise numbers, which are irrelevant in Agile estimating and can lead to futile and destructive disputes.
  • It can be fun, especially when the team generates alternative scales – sizes of animal, planets, etc.

Unfortunately, T-shirt sizing also has a number of severe limitations:

  • Estimates can be dominated by the more vocal members of the team.
  • If the sizes aren’t quantitative (or even quasi-objective measures likes story points), how can the team decide when they have enough stories for a complete iteration?
  • How is the team’s velocity to be calculated?
  • Stories sizes can’t be aggregated – how large is XS + L + XXL + 3*S + 2*M? But this is essential is the team wants to estimate the effort needed to implement a  complete epic.

Some teams assign each size band a definite number of story points. But this seems to complicate the process without explaining why, if this is what the sizes really mean, the team should not just use story points.

Ideal days

The ideal day is a simple idea: that it should be possible to define how long it will take to complete a story, if only it were possible to not be interrupted, etc.

In fact the idea of an ideal day assumes:

  • The story is the only thing the developer/user pair work on.
  • The team have no distractions.
  • Everything the team need is directly available, including tools, data, materials, etc.
  • And including appropriate user support (i.e., an expert, empowered user).
  • The work matches the skillset of the individuals (user and developer) who will carry it out, so it will be done efficiently, with (relatively) few errors or omissions.

In many organisations, the assumption is even simpler. Allowing for all the times when the above assumptions are not true, the team are typically left with a 6-hour working day. So an ideal day is a 6-hour day. It’s not as subtle a method, but it does take into account the fact that there are always other demands on the team.

Using ideal days is helpful because:

  • It creates a practical context for estimation that everyone can grasp easily.
  • It simplifies the transition from traditional estimating.
  • It translates readily into a delivery schedule.
  • It makes progress more visible.

But ideal days also pose a problem. Because they define a specific rate of activity, they encourage others (Product Owners, Iteration Leads, PMOs and stakeholders) to pressure the team to work faster and accelerate delivery. So they will be tempted to insist that a story the team estimates will take, say, 4 ideal days can be done in 3. This re-creates all the risks the original idea of story points as something that the team defined for itself was designed to remove.

Counting stories

For very advanced teams, there is a much simpler method of estimating.

Treat all stories as being the same size.

  • Count how many stories you’ve completed in previous iterations and releases.
  • Assume you’ll complete about as many in the next iteration.
  • That’s it!

In short, what you’re doing here is calculating your velocity in terms of whole stories, not story points.

The explanation for this approach is simple.

  • Individual stories will vary in size.
  • But if you take, say, a set of ten stories at random, the average size of the set will be similar every time you select a new set.
    • This is because the smaller and larger stories will tend to balance each other out.
  • So if you are selecting the stories for a complete release or iteration, you’ll probably have much the same number of stories each time, even if the individual stories are very different in size.

This technique is based on a number of assumptions only mature teams can afford to make:

  • Authors of stories can be expected to break stories down to more or less the same size.
  • The team is so good at breaking epics and features down into individual stories that they can realistically assume that the resulting stories will all be of more or less the same size.
  • Over time, the team won’t tend to drift towards larger or smaller stories, causing their estimates to wander too.

Only a very good team can afford to estimate like this. But if you are that good, a more complex approach really is unnecessary.

Planning Poker

Planning Poker is one of the best known and most widely used of Agile practices.

It has many advantages:

  • It is especially well suited to teams with mixed levels of experience and confidence.
  • It includes all team perspectives & skills.
  • It ensures that everyone expresses their opinion independently.
  • It lets the inexperienced estimators learn from the more experienced.
  • It prevents louder, stronger characters from dominating the final result.

The game is simple. Starting with the highest priority story and working downwards, for each story:

  1. The Product Owner reads the story out to the team.
  2. The team ask as many questions as they need.
  3. Each team member writes their estimate on a card or piece of paper, not showing it to anyone.
  4. When all are finished, they reveal their estimates together.
  5. If the estimates are the same, that is the team’s estimate.
    • The team may agree to ignore very small differences.
  6. If estimates differ, the individuals who made the high and low estimates explain their figures.
  7. The team discuss their explanations.
  8. The team re-estimate the story.

The game also has a few supporting rules:

  • Any story that is too vague to estimate should be returned to the backlog for clarification.
    • It should not be ‘clarified’ during planning meetings.
  • All team members estimate each story.
    • Any team members may need to work on a single story at one time or another, so everyone’s opinion of its difficulty is important.
    • The team’s collective expertise and diverse perspectives should improve the estimate.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?