Scrum Estimation Tutorial

8.1 Scrum Estimation

Welcome to lesson-8 of Simplilearn’s Agile-Scrum training program. In this lesson, we explore how estimation is done on Scrum projects. There is a lot of (at times excessive) importance attached to the process of estimation, which is often over the top. Scrum establishes simple techniques of coming up with quick but reliable estimates, with the added advantage of being able to refine the estimates from the actual experience of working on Sprints. Let us begin with the agenda of this lesson in the next slide.

8.2 Agenda

We will now look at the detailed agenda for this lesson. We start off by setting up some “first principles” that guide us through the process of estimation on Scrum projects. We then look at different types of estimates that are done at various points on a project. The classification could be on the basis of the method used to arrive at the estimates or the confidence level we have in the estimates. Next, we look at the units of measuring size of software. Typically on an Agile project, we use either story points or ideal days to express the size estimate. Then we talk about the techniques of estimation that are commonly used on Scrum projects. Here we focus on two techniques called Planning poker and Affinity estimation. We will now start off by looking at the Principles behind Scrum estimation.

8.3 Principles behind Scrum estimation

Let us establish some common ground before diving into techniques or units of estimation. The first thing to understand is that an estimate is after all – AN ESTIMATE. It is a forecast, a guess based on available information. It is neither a life-or-death matter nor a sentence to live with for the rest of the project. -Accuracy and precision are terms that do not go well with the term estimation. Achieving precision in estimates is neither possible nor necessary. As long as you are able to forecast with reasonable certainty and come up with a predictable plan, you should be fine. -The team which is actually doing the work should have the last word in finalizing estimates. Others are free to have an opinion, and they are allowed to ask clarifying questions about the basis on which the estimates were arrived at, but ultimately the only estimates which matter are to be given by the team. -As time goes by and as more and more information about the activity becomes available, the estimates will become closer to reality. -The thing about Scrum is that if your estimates are far from reality, you will get very quick feedback. Bad estimates will be exposed sooner! This is actually a good thing, because it allows you time to make the adjustments necessary to make your plan more realistic. - In the next slide we will learn about Estimation techniques.

8.4 Estimation techniques

Broadly, estimation techniques can be classified as top-down or bottom-up. Bottom-up estimates are also called detailed estimates and these are based upon a detailed work-breakdown-structure. The WBS whittles the requirements and deliverables into smaller units. The granular estimates are rolled up at a higher level to arrive at the aggregate estimates. Top-down estimation on the other hand looks at the big picture and without getting into too much detail, tries to arrive at fairly coarse but reliable estimates. Variants of top-down estimates are as follows. -Expert estimate: Expert estimation involves asking an expert who already knows about the work. Based on their past experience and knowledge, they will be able to provide estimates without getting into too much detail. -Analogous estimate: Analogous estimation relies on drawing an analogy with another similar project or requirement. Based on the analogy, and based on past experience with the analogous project or requirement, you can come up with the estimate. -Parametric estimate: Parametric estimate relies on some well known or industry recognized parameter to convert a known variable (like lines of code or function points) to a time or effort estimate. -Let us now understand the types of estimates in the next slide.

8.5 Types of estimates

The different types of estimates based on the range of variability are as follows. -Order of magnitude (sometimes called Rough order of magnitude): These estimates have a projected range of -25% to +75%. They are used typically for go-no go type of decisions. -Budgetary: These have a projected range of -10% to +25%. They are used for budgeting purposes. -Definitive: These have a projected range of -5% to +10% and can be used for planning after most of the information is available and is factored in. Notice that there is always a range of values that are projected, recognizing the fact that it is after all an educated guess. Also notice that the range is always skewed on the higher side, because you need a greater buffer on the positive side. Now, we look into a figure in the next slide describes the Uncertainty of estimates.

8.6 Uncertainty in estimates

The cone of uncertainty is an interesting way of show-casing the inherent variability in estimates. Early on in the project, the range of possible values is a lot higher (nearly 4 times on the positive side and up to 1/4th on the negative side). As the project makes progress and more information becomes available, the variability narrows down progressively. Project managers believe in estimating based on historical data and empirical observations (in other words rationally) and prefer to err on the side of caution (a prudent strategy). Engineers tend to underestimate, and always believe it would take less time than the actual. Executives on the other hand tend to under-estimate on purpose because of their inherent belief that the team always wants to over-estimate and hence they feel the urge to squeeze the estimates. Next, we will discuss in Over-estimation and under-estimation.

8.7 Over estimation and under estimation

Under-estimation is typically under-estimated and over-estimation is typically over-estimated. Managers and executives always feel the urge to deal with over-estimates, but rarely bother to address under-estimation. However, history shows that under-estimation is a lot more prevalent and potentially lot more dangerous. “Nothing is impossible for the man who doesn’t have to do it himself” says A.H.Weiler – again leading to the conclusion that the only estimates which matter are those given by the team doing the work. Hofstadter’s law states that it always takes longer than you expect, even after allowing for Hofstadter’s law (recursive logic!). In the next slide we will understand what contributes to size.

8.8 What contributes to size

The size or bigness of a task is governed by the complexity, riskiness and the volume of work involved. You can apply these correction factors to correct your raw estimates based on this empirically derived formula. Adjusted size = Raw size * (1 + Complexity factor + Drag factor + working environment + multiple teams). Complexity factor represents how complex the work is. Drag factor considers whether the team is familiar with each other before or required time to get together. Working environment considers whether the infrastructure required for the project is present and is in good condition. Multiple teams represents the adjustment to the fact that potentially multiple teams need to work together on a project. Let us now learn about Measures of size.

8.9 Measures of size

In traditional (sequential) projects, the commonly used size measures are lines of code or function points. In Scrum, the estimates are normally expressed in terms of ideal days or story points. While story points or function points may be considered “Pure” measures of size because they are unitless, LoC or ideal days are based on a parameter. Function points or lines of code do not make sense on Scrum projects because of the fact that the requirements in Scrum are expressed in smaller units (stories), they are evolving and not expressed in as much detail as they might be on traditional projects. Furthermore, Scrum believes in lightweight methods even for estimation – that give just enough predictability to the plans. Both LoC and Function points require a lot more rigorous analysis, which may not be done in Scrum projects. We will discuss on Ideal days in the next slide.

8.10 Ideal days

An ideal day estimate answers the question – how long would this story take to complete if it was ALL that I worked on, had no distractions whatsoever and everything that is required for the story (in terms of clarifications, dependencies) is available. Once you do arrive at the ideal day estimate, you would then convert it to the actual (elapsed) days based on the level of distraction to be accounted for. For example, the distractions arise from the following. -Time spent on doing email -Time spent on personal work -Time spent on meetings that are not connected to the task at hand (e.g. town-hall meetings) -Time spent on breaks for tea, lunch, etc. Basically anything that does not directly contribute to the work at hand may be considered as a distraction. Next we will discuss on converting ideal days to actual days.

8.11 Converting ideal days to actual days

In order to get to actual (or elapsed) days from ideal days requires you to take into consideration the following factors. -How much distraction needs to be accounted for -Whether the resource has other tasks assigned -Who is actually doing the work (expert or novice) Look at the story given and try to think about the ideal days required to complete the story. Now how would you translate that into actual days based on your hypothetical “availability” to do the work? In the next slide we will focus on the story points.

8.12 Story points

Story point is a pure unit of measure for size that relies upon the analogous estimation technique. It works as follows. -Think of a benchmark story having a fairly small size and assign it a story point of 1. -Then assign story points to all other stories relative to the benchmark story. oIf it is twice as big, then the story point is 2, thrice => 3, etc. -Remember that absolute values are unimportant – it is the relative values that matter. -Also remember that the points are based on the entire effort needed – not just the coding or testing effort. -Let us look into the Story point’s example, in the next slide.

8.13 Story points example

As an example, take a look at the example story given and compare it with the previous story. If the previous story had a story point of 3, what would be the story point for the new story? Now if the previous story actually took 5 days to complete, how many days would the new story take? We will now discuss some best practices, using story points.

8.14 Using story points

Here are some best practices around the use of story points for estimation. -Do not use a single benchmark or gold standard. You can use triangulation techniques. -For example, you may choose a small story with a story point of 1, medium story with a 5 and a large story with a 13. Roughly, your medium should be 5 times the small and large should be 2.5 times the medium. -When you encounter a new story, you have three benchmarks available to you for comparison and you will be able to comfortably place this story with the right story point in comparison to the others (e.g. bigger than small but smaller than medium, etc.). -Story points are usually assigned on a non-linear scale. This means you cannot assign any random value to the estimate, you have to pick the closest value from any non-linear scale (examples below). The idea behind this is that it is easier to agree on an estimate this way. For example – it may be hard to settle an argument whether an estimate is a 16 or a 17. But if you ask if it is a 13 or a 20, that might be an easier question to answer. oModified Fibonacci series: 1, 2, 3, 5, 8, 13, 20, … oDoubling scale: 1, 2, 4, 8, 16, … Next, we will understand comparing the approaches.

8.15 Comparing the approaches

So how would you compare the two units of size measure used on Agile projects, viz. Ideal time and Story points? Story points have the advantage that: -They help drive cross-functional behavior. Because the size is measured at the aggregate level, it does not differentiate between coding or testing or documentation time. -Story point estimates do not decay with time. Since it is based on comparison, the value of story points would not change with passage of time. -Story points are a pure measure of size, i.e. they are unitless. -Story point estimation are usually faster once you get used to it, because human mind is better able to handle comparisons than it is able to process absolute values. On the other hand, while expressing estimates in terms of ideal days: -You need to be aware that ideal days may be different even for two different members of the same team. For example, an experienced developer may have a lower ideal day estimate as compared to a junior developer. -Ideal days are probably easier to explain than story points, since the latter are more abstract. -Ideal day estimation is easier at first – since for story points, one needs to establish and solidify the benchmarks. -Ideal days can help the group draw sharper focus on the time wasting activities and help the team focus more on the development activities. In the next slide we will learn about Estimation techniques – Planning poker.

8.16 Estimation techniques Planning poker

Having discussed the units used for estimation, let us now spend some time to understanding some of the techniques that can be used to arrive at these estimates. We start out with planning poker, which is an iterative approach and a fun way to arrive at fairly accurate and quick estimates. The steps involved in planning poker estimation are as follows. -Each team member participating in the estimation process is given a deck of cards containing the allowed estimate figures on the non-linear scale. For example, if the Fibonacci series is being used, you would have cards bearing numbers 1, 2, 3, 5, 8, 13, etc. -The customer or product owner reads out the story to be estimated and gives the details to the team. The team discusses the story and possibly asks clarifying questions to arrive at an initial understanding of what is required to be done. -Now each estimator (on his/her own) selects the card that matches their estimate for the story and puts the card face down on the table. -Cards are turned over all at once so that everybody can see them. -Typically there will be a range of estimates chosen by the team. Now the team should discuss the differences in the estimates and the rationale behind them. Typically, the outliers (the highest and lowest) would be explained and rationalized. -After the discussion, the team again picks up the cards and estimates in the same fashion as before, until the estimates start to converge. Then the team estimates again in the same manner until they reach consensus. Let us now look at an example of planning poker in the next slide.

8.17 Planning poker an example

In this example, Erik chose an estimate of 3, Martine chose 8, Inga chose 2 and Tor picked 5 in the first round of estimation. After a round of discussion, they later chose 5, 5, 5 and 8 respectively. At this point the estimates are fairly close. You may ask the team members if they want to go with the majority figure (5) or be conservative and choose the higher estimate (8). Now, we will look into some tips to make planning poker work better.

8.18 Planning poker tips

Here are some tips to make planning poker work better for your team. -What if the discussion lingers too long? oThe scrum master should ensure that the discussion is focused on the topic oThe scrum master will often keep a timer to limit the discussion -What if the estimates by team members never converge? oThe scrum master can ask the team if they want to go with the majority view oIf you know who is actually going to do the work, you may want to go with their estimates oBe patient and let the team come to an agreement about what they want to do. Do not force your views on them. -You can take a look at this website ( for guidelines tips and tricks and also an online version of the game. -In the next slide we will go through the advantages of planning poker.

8.19 Advantages of planning poker

What are the advantages of planning poker? -It gets the whole team involved oTeam involvement generates more “buy-in” with the estimates and ensures the commitment from the team oEverybody gets exposed to all the stories in play oEverybody’s experience is utilized in coming up with the estimates -It triggers lots of useful discussion oDiscussion helps in clarifying the requirement oDiscussion also focuses attention about the technical approach and the design proposed oDiscussion brings out potential challenges and risks oDiscussion helps focus attention on coming up with the best possible guess Now, we will discuss on Affinity estimation.

8.20 Affinity estimation

Affinity estimation is a technique that can be used to quickly estimate a large number of stories. For instance you could use it just before release planning or budgeting process to quickly arrive at coarse level but fairly reliable estimates without wasting much time. The characteristics of affinity estimation are that it is quick and easy. It makes the decision making fairly transparent and visible. It aims to create a positive and collaborative experience rather than a confrontational exercise where people argue about the estimates. Let us focus on the Affinity estimation: Process.

8.21 Affinity estimation process

The flow of the steps in the affinity estimation process is as follows. First, the team writes down the stories provided by the product owner, one on each post-it note or card. The team then establishes the relative sizes of the stories. The team arranges the stories in ascending order (from smallest to highest) on a horizontal scale. It may be done by re-arranging post-it notes or index until the entire team is satisfied with the order. This step could be performed “silently” as in mute-mapping; to keep the process quick and non-confrontational or you could allow discussions during this process. Next, the team members edit the relative sizes on the wall. This may also involve discussions with the product owner and the team can optionally rearrange the order that was decided in the first step based on their relative sizing. We will continue with this topic in the next slide.

8.22 Affinity estimation process

Next, the items are placed in specific “buckets” which may be labeled according to the estimation scale of choice. For example, the buckets may be labeled Extra Small, Small, Medium, Large and Extra Large or it may be labeled based on a non-linear scale with story point values (1, 2, 3, 5, 8 and 13). After the team finalizes the estimates, the data is stored and the process closes. Now, we will move on to the next slide where we find few quizzes related to this lesson.

8.23 Quiz

Let us quickly test our understanding of this lesson through this quiz. Which of the following estimation techniques will you use when you have a large number of stories to estimate? A-Planning games B-Affinity estimating C-Ideal days D-Wideband delphi Answer is B: Affinity estimating helps you arrive at fairly reliable estimates at a coarse level fairly quickly. After several rounds of Planning poker, the team is unable to agree on the estimate for a story. Half the people feel it is 8 story points and the other half are leaning towards 13. Which estimate should be used? A-8 B-13 C-The team decides D-The scrum master decides Answer is C: The team has to agree on the estimate (whichever value they pick is immaterial The Product owner asks the team member how long a story would take if she was only working on that story. Which measure of estimation is being used? A-Ideal days B-Calendar days C-Function points D-Story points Answer is A: Ideal days expresses the time it would take under “ideal circumstances”, i.e. with no distractions. Which estimation technique is MOST unlikely to be used in Scrum? A-Analogous B-Detailed C-Expert D-Parametric Answer is B: Scrum relies on top-down macro level estimates. It does not help to get into too many details while estimating. We thus end this lesson on Scrum estimation. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers the ninth lesson of this course which is about Monitoring Scrum Projects. Happy learning!

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*