In our previous post, we’ve discussed some of the main things to know about Scrum and its terminology and we showed you how high level-planning works in Agile frameworks. This time we’re going to write about something that deserves its own post: Estimation.
If you work in software development, sooner or later there will be a time when you have to estimate for a task or a project and it’s a dreaded moment for everyone involved. Developers hate it because usually they have to estimate tasks that are hardly defined to any degree, while managers hate it because poor estimates create a lot of headache and they constantly have to battle schedule and budget problems which these estimates inevitably create.
Regardless of project type, the person who will do the actual job will need to give an estimate to the client, so they can base their decisions on those estimates. This is the same when it comes to software development also. Estimation itself is completely independent from project management methodology, the only thing that differs are the techniques and the metrics used.
In traditional waterfall models, projects are broken down into modules and then - in better circumstances - into work packages. When the work packages of the project have been identified, and verified, development teams start estimating them in man-hours/days/weeks. Once they have an estimate for all work packages they summarize the hours which can then be communicated to management or the client. This is called bottom-up estimation. If the company’s project managers are more knowledgeable or there is a PMO present who can supply the right tools they will use a technique like the Critical Path method (We will discuss this method in a future post) to model the project’s forecasted progress, task dependencies and calculated floats between tasks. This also takes resource availability to calculation. If the team uses a three-point system in their estimation along with Beta distribution you’re in “estimation heaven”. The main problem of this process is that it takes a lot of time and thus costs a lot of money. It’s also difficult to explain to clients, so these techniques usually get used less and less, and in some cases companies fall back to inaccurate and impossible estimations (not all but it happens).
Scrum does this a bit differently. Scrum teams estimate in Story points (SP) instead of hours. The main difference compared to estimating in hours is this way Scrum teams don’t have to give exact time estimations on a given task, but instead they can estimate the effort needed to complete the task. Story points are a relative metric, which show the approximate effort and complexity that will go into the task or story, basically creating an abstraction. This is all well and good, but all businesses revolve around money and story points can’t be converted to money or time (as always time = money). There are formulas for it, but that’s an entirely another discussion.
Companies using agile frameworks need something more to convince their clients or their management and this is where team velocity comes in. We’ve discussed this concept in the previous post. This is the capacity of the team, namely, how many story points they can complete in a sprint which is always a predetermined timeframe (usually 1, 2 or 4 weeks). If an agile team tells someone that the feature they have requested is estimated at 13 story points, they will find people scratching their heads. But if the same team tells the client that in one sprint they can complete four or five similar sized features, then it is an entirely different story. Clients will be more receptive of this idea.
It's very important to note at this point that there is no correlation whatsoever between story points and time. A lot of beginner teams fall into this trap and it is a very tempting trap. Although there’s obviously some kind of connection between the two, meaning that a higher story point number will probably mean there is more work to do and because of this it will take more time, but this isn’t always the case. Remember, story points represent a combination of effort, complexity and even doubts. The best example would be the following hypothetical conversation between two developers:
“Maybe it will take you 4 hours to do this, and 8 hours for me, but we both agree that looking at this task compared to the rest, this is definitely a 13 SP story.”
When it comes to estimations in Scrum, teams can only use pre-determined values. These usually come in the form of a modified Fibonacci sequence (There are way more, but this is the most widely used) with the following numbers: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. With these numbers, Scrum teams can compensate for the uncertainties stemming from the complexity and effort not always known beforehand. The previous conversation illustrates this perfectly. The higher the number, the higher the uncertainty is about the story, and this means the story requires either more decomposition or more clarity.
When it comes to estimation accuracy humans are simply not good at it. Thankfully there are a lot of tools and techniques to help teams achieve better estimations. Just because we’re bad at it, doesn’t mean we shouldn’t try, right?
When it comes to estimation accuracy/quality there are three main classes. These in order of quality are: Rough Order of Magnitude (ROM), Preliminary and Definitive. In more scientific circles these are classified in reverse order ranging from 1 to 5, where Class 5 means the lowest accuracy and Class 1 the highest. In this context Class 5 is the Rough Order of Magnitude estimation. Usually a Class 3 estimation (Preliminary) is enough to calculate a budget, especially because at the start of every project uncertainty will be the highest and basically unavoidable. The following figure offers more explanation:
You can clearly see on this figure that as time moves forward, uncertainty is decreasing but never disappears and adversely accuracy increases.
In most projects, there’s simply isn’t enough time to get to a Class 1 estimation and it’s counterproductive, since the required definition level of the project for that is usually achieved at the end of the project or at least most work is usually done by that point.
As we’ve said before, Scrum uses relative sizing. When it comes to accuracy it is easier to compare one task to another. It is especially hard to estimate something that you only have a vague idea how to complete. Story points provide the solution for this, as they come from a pre-defined pool of numbers so teams can quickly come to a consensus about which numbers to use in certain situations.
E.g. If a registration form they had to do in the past was 13 story points, then a whole cart page with all its functionality will be around 2 to 3 times that and the closest number they can use from their modified Fibonacci sequence in this case will be 40. A good advice for teams is to select one story so they can know it’s story point worth (because the team did it before) and use that as a benchmark for the rest of the stories.
Story points usually take three main aspects into consideration:
As we’ve stated at the first part of this post, the next step after estimating story points is figuring out the team’s velocity. This is hard for fresh or newly formed scrum teams as they won’t have an idea since there is no historic data to base their assumptions on. The easiest way in these cases is just guessing a reasonable velocity for the first few sprints and use the Yesterday’s weather technique. This involves paying close attention to the team and the speed at which they can complete their stories for 2 or 3 sprints and take the average of their total throughput. The number you receive will be the team’s velocity. This technique can be used for more developed teams also, as team velocity can change over time for a variety of reasons and knowing your team’s capacity is paramount in project success.
Taking everything into account there is no “silver bullet” when it comes to estimation. Both agile and waterfall uses a wide array of tools and techniques to combat uncertainty and poor estimation accuracy. At the end of the day all teams and managers must decide what is best for them and perfect those as they move forward. Our best advice is to keep a record of your estimations and keep going back to them and revise them as necessary. This way you’ll have a historic database of certain features you’ve already built and completed. This will allow teams to perfect themselves and always have something to benchmark their estimations against.
In the next post, we’ll discuss the most common tools and techniques used for estimation in agile and how they compare to waterfall.