This chapter covers the following topics:

INTRODUCTION

Accurate estimation is essential to all types of change projects, but the Just Enough, Just in Time concept presents new challenges for business analysts working alongside or within agile teams. When the detail of project scope is not known up front, how can the team provide useful estimates?

This chapter introduces the key principles that underpin most agile estimation techniques, and puts them into context. Examples demonstrate how agile teams use estimation in practice and highlight how these techniques can be utilised effectively by business analysts.

AGILE ESTIMATION APPROACHES

Business analysts will be familiar with estimation, and there are many well-documented techniques and methods. Estimation on agile projects is just as important as in other types of project, but there are a few differences and a few new techniques. These techniques apply to all types of project, not just those involving software development.

Agile approaches are different to traditional approaches and it is important that business analysts understand these differences if the agile values and principles are to be upheld.

The agile values promote ‘Responding to change over following a plan’ and ‘Customer collaboration over contract negotiation’, and there is a principle that ‘Working software is the best measure of progress’. Some sources have now replaced ‘software’ with ‘product’, which accepts that elements of a product, other than software, should be considered.

Consequently, these agile values and principles suggest that estimates should be treated in a somewhat different way from traditional projects. Specifically, agile teams approach estimation with an assumption that the factors that contribute to the estimate will change, and hence the estimates will change. This means that it is vital to understand what is being estimated, and why. An estimate is a best guess, based on the knowledge that the team has at the time. It should also have a tolerance, or margin of error. This might be quite large at the start of a project, because so many things have the potential to change. As the project proceeds, more things become certain, risks are reduced and the estimates can be more precise. In addition, more of the work has been completed, leaving less work still to be done.

This is, in some ways, similar to what happens on traditional projects – the initial estimates may be updated as the project progresses, usually at the end of the project stages. The difference with agile estimating is that it is done on an ongoing basis, and there is a focus on preparing detailed estimates only for elements that are required in the near future and not on estimating elements that may never be developed.

It should be noted that all estimates made during the course of the project are acceptable; it’s just that early in a project, the estimates are less precise and more subject to change. Figure 14.1 below illustrates the estimation cycle used in an agile project.

 

Figure 14.1 Estimation cycle

WHY AND WHEN TO ESTIMATE

Estimation is required at all stages of an agile development cycle, and will serve different purposes at each stage.

ESTIMATION TECHNIQUES

Agile estimation approaches mostly rely on the whole team contributing to the estimate (Wideband Delphi), because the whole team (including business analysts) will be delivering the project; and on some form of relative sizing, because humans are much better at comparing things than at calculating actual numbers. These approaches allow agile teams to come up with helpful estimates that are accurate enough without attempting to be highly precise.

Wideband Delphi

Wideband Delphi was developed in the 1970s by Barry Boehm and John Farquhar. The technique relies on obtaining estimates from suitably qualified people and then synthesising them to produce the final estimate. Most agile estimation techniques rely on the theory of Wideband Delphi and some form of relative sizing.

General process

• Each estimator is given a specification of the work (activity, task or deliverable) and is asked to provide their estimate for it. These estimates are compiled anonymously.

• The estimates are then summarised (still anonymously) and the summary is circulated to all the estimators.

• Estimators reconsider their own estimates in the light of the summary and provide a revised estimate if they wish.

• The above process is repeated as many times as necessary to achieve a reasonable consensus.

The participants bring different experience and knowledge to their estimates and, because the estimates are anonymous, personal disagreements are avoided and the estimates can be considered objectively.

Relative sizing

Most people have difficulty in defining precise estimates for complex tasks. However, they find it much more straightforward to make comparisons between estimates for different tasks.

Relative sizing is a way of using experience to gauge the size of something using historical information or judgement. It can allow very precise estimates, quickly, without requiring complex analysis.

The concept can be illustrated with the jar of jelly beans shown in Figure 14.2.

 

Figure 14.2 Relative sizing using jelly beans

Trying to estimate the number of jelly beans is a surprisingly difficult task, because there is no reference point upon which to base the estimate. However, if the number of jelly beans in a full jar is known, the problem becomes much simpler. This is because humans are very good at judging relative sizes – we find it quite straightforward to tell that something is twice as big or four times as long. Therefore, being told that a full jar contains 440 beans makes estimating how many are in the jar in Figure 14.2 much easier, and results in a much more precise and accurate estimate.

This is fundamental to agile estimation; comparing the requirement or item being estimated to previous items results in a much more accurate estimate.

The things being compared don’t have to be exactly the same, they just need to be similar enough that they can be compared. For example, being told how many smarties were in a full jar should still result in a reasonable estimate of the number of jelly beans in the half-full jar.

Estimation units

Teams can estimate in any unit that helps them. The advice is generally to try to avoid using actual time units (like days or hours). Some commonly used units are shown in Table 14.1 below.

 

Table 14.1 Commonly used estimation units

User stories, epics or number of requirements	Especially useful at the ‘whole-project’ level as they are relatively easy to count. However, since stories are not all the same size it can be misleading. You can use epics or separate stories in small, medium or large stories to make the process more granular (for example, a 25 epic, 40 story project).
Story points	A very commonly used abstract unit. What one point means will differ between teams, so it is important that everybody’s view of a point is the same.
Ideal developer days/hours	This assumes a developer could spend all the time on the work. Can be helpful to provide consistency, but it is easy to underestimate the non-coding time in real life, especially when deciding how much work can be done in an iteration.
Days/hours	Seemingly logical, and easy to map into available time, but notoriously difficult to get right. Common in non-agile projects but, really, only good for simple, well-understood tasks.
Abstract units	Non-numeric and abstract representations of size. Examples are small, medium, large, extra-large. Or using more abstract terms: animals, area, volume and so on. Like story points, they abstract away from real life, but the whole team needs to know what they mean and how they relate. Sometimes called Nebulous Units of Time or NUTs.

Up-front estimation

At some point in almost every project, usually around the start or before it begins, somebody wants to know what will be delivered, when and at what cost. Given what we know about agile projects, this is a hard question to answer. There is usually more work to do than the team will have time to complete, and the customer is rarely certain on scope and detailed requirements at the beginning.

To estimate how long a project might take, a traditional team may try to break down all the requirements, estimate all the parts, add up the days and add some contingency. An agile team might approach that differently:

Taken at first glance, that seems a very bad way to come up with an estimate. However, because the agile team will be delivering the product in a prioritised way, the most important work will be delivered first. So, even if the estimate is too low, and the project has to stop before all the requirements are delivered, the missing requirements will be the lowest in priority. It requires trust between the project sponsors and the team and, for teams working in a commercial context, the contract and commercial terms need to be carefully considered.

This type of approach follows many of the agile core values and principles – it is iterative, involves the whole team, uses just enough detail, and focuses on value to the customer. It is also a good way to access the team’s tacit knowledge in a way that an analytic breakdown of the problem isn’t able to do. Business analysts play an important role here, particularly with their ability to think more broadly than just about the tasks of the team, and to consider people, process, organisational and facilities aspects in addition to software.

This overall approach can be applied to all kinds of estimation with agile teams, including non-IT projects. The key thing to remember is Just Enough, Just in Time. For example, items on the product backlog aren’t committed to at this point, so only need rough sizing, and low level tasks during an iteration might not need an estimate at all.

Relative estimation (bucket method)

In this technique, a small set of estimation categories or buckets (perhaps 3–5) are chosen as the estimate results. The team start with a story and decide which bucket it should belong in. The next story is then discussed, compared with the first, and a bucket chosen for it, and so on.

This is a good way to roughly divide up a backlog, and it can be particularly effective when used at product backlog level. Because there are only a small number of possible values, and they must cope with the smallest to largest story, the results can be a little coarse for some types of estimation.

Examples of this include ‘T-shirt sizing’, where the ‘buckets’ are T-shirt sizes, such as extra-small, small, medium, large and extra-large. Other teams use groups of animals (small animals, medium sized, etc.) or measures of volume (shot, half, pint, etc.). This method can also be used with a very limited number of choices (big/small).

Ordering

Sometimes called Relative Mass Estimation, this technique uses an intermediate ordered stage. This means it can also be used for prioritisation, and can be used for ordering and estimating other attributes, not just work. It is applied in the WSJF prioritisation technique used in some agile methods (see Chapter 9).

To begin, all the items being estimated should be on cards that can be moved around a large table.

This results in a very visual representation of the work the team has to do, with the hardest work at one side and the easiest work on the other.

Finally, the stories have a numeric estimate placed on them. This can be done by starting at the easiest story, allocating it 1 point. The team members then work their way up through the stories, allocating each story 1 point until the team reaches a story that they think is twice as difficult as the first story. This gets 2 points, and so on. Any numeric sequence could be used, including Fibonacci, or one of the relative sizing methods mentioned above. The important thing to remember is that it is a rough estimate and not to dwell too much on the value.

This technique can also be used to assess priority of stories, and can be gamified where players take it in turns to move cards around the board, challenge decisions or add a new card.

Divide to size

This method aims to get all the items the same size as one another. The team begins by deciding what size that should be (say, 5 points, or 1 ideal developer day). After that:

Planning Poker®

There are several variations of planning games that agile teams use at various times to help make estimation more fun. The most well-known is Planning Poker®, which was developed by Mountain Goat Software. This game uses special cards to limit the choice of estimates to promote discussion and help to reach consensus more quickly.

The game is played by the whole team, and can be used for estimating anything with a numeric unit. It is commonly used to size user stories for the backlog. The game uses sets of cards (See Figure 14.3) with a sequence of numbers printed on them. The numbers usually follow a modified Fibonacci sequence (such as 0, 1, 2, 3, 5, 8, 13, 20, 40, 100).

There is a lot of uncertainty in estimation, so having discrete choices forces teams to converge on a single number. Discussions about the uncertainty are encouraged as the gaps between the numbers increase. Some packs of cards add in ½, infinity, ‘don’t know’ and a request for a break. The numbers can represent any numeric unit.

 

Figure 14.3 Planning Poker® cards

Playing Planning Poker®

The game is played in an estimation workshop or planning meeting. For each story to be estimated, the team goes through the cycle shown in Figure 14.4.

 

Figure 14.4 Planning Poker® process

The process should involve the whole team, and it is preferable that the team members are co-located. However, there are electronic versions of the cards available to allow remote participation. Before the meeting, the team must have a common understanding of what the values mean. Typically, they will pick a story everyone is familiar with from an earlier iteration and agree how many points that story represents. They can then apply relative sizing judgements to estimate the new stories. The numbers matter – an 8-point story should be about four times as difficult as a 2-point story.

This game can be modified in a variety of ways. Teams can choose their own numbers or number sequences, or even choose non-numeric votes such as different sized shapes or animals (for example, flea to elephant).

One of the problems with using numbers is that people naturally relate them to days’ effort. This can be misleading because different people work at different rates, particularly in a multi-disciplinary team of generalising specialists. Using days as a unit can also be easily misinterpreted by other stakeholders, particularly where the estimates have not taken account of other activities like holidays, training or management meetings and there is confusion between the concepts of effort and elapsed time.

The game is usually (but not always) used to judge story size and the relative time a story will take to deliver. Business analysts have an important role to play, as they can often bring insights to the team that will affect their estimates. For example, a business analyst might point out that user experience testing will require more users than the developers thought, or that a business process will require updating, which is additional work. They may also be aware of complex business rules that underlie some stories.

CONCLUSION

Estimation is not an exact science: estimates are almost always at least a little bit wrong; and sometimes a lot wrong. Agile projects expect and anticipate change, so agile estimation must also expect change. Largely, that means doing as little work as possible to get to an answer that can be used.

There are many different ways to estimate. Most rely on collaboration and the experienced expert principles of Wideband Delphi. They also apply a form of abstract relative sizing.

The key things to focus on are that the whole team has the same understanding of the units being used and to apply the Just Enough, Just in Time principle.

FURTHER READING

Ambler, S. (2009) Dr Dobb’s Journal. Lies, great lies and software development project plans. UBM. Available at: www.drdobbs.com/architecture-and-design/dr-dobbs-agile-update-0709/218700176 [20 December 2016].

Ambler, S. (n.d.) Agile Modelling. Ambysoft Inc. Available at: www.agilemodeling.com [20 December 2016].

Boehm, B. (1981) Software engineering economics. Englewood Cliffs, NJ: Prentice Hall.

Cohn, M. (2005) Agile estimating and planning. Upper Saddle River, NJ: Prentice Hall.