When a new project is about to start, the project sponsors definitely want to know how much time it will take to complete it. If, on the contrary, you’re already involved in an ongoing project, project stakeholders probably are eager to know what amount of work you as a team will be able to complete during each subsequent iteration. We usually use different estimation techniques to provide the mentioned information to the project sponsor or stakeholders in both cases. On the basic level, we typically break all the work into smaller chunks, estimate these chunks in working hours or days needed to complete each of them, get the sum of these estimates, and compare to the team’s capacity.
Estimation in working days or working hours (if better granularity is needed) is the most intuitive approach which has been used since the project approach to doing the work emerged. However, it turned out that estimation in working hours (or so-called man-hours) has its limitations and drawbacks, and it is not always helpful. With the development of Agile practices, new estimation practices have also emerged based on different measurement units, which are called story points.
What are story points?
Unlike man-hours or working days, which are absolute units of measurement of time, story points are relative units of measurement. They show how bigger a particular task (story) is compared to a standard unit of 1 story point. The interesting thing is that there is no common absolute value of 1 story point. Each team decides on their own what exact amount of work is equal to a standard 1 story point.
Another difference between story points and man-hours is that a story point is not even a unit of measure of time at all, it is instead a unit of measurement of effort needed. The estimate of a particular task shows how much effort is needed to complete this specific task compared to an amount of effort needed to complete the smallest standard task of 1 story point. For example, a task estimated as 2 story points should be twice as much in terms of efforts as a task estimated as 1 story point. That’s why the scale is essential when estimating in story points.
The most popular story points scales
There are two most popular scales for story point estimating – a linear scale (1, 2, 3, 4, 5) and a Fibonacci sequence (1, 2, 3, 5, 8, 13…). Some practitioners claim that the Fibonacci scale works better because it gives team members more room for agreement on the conclusive story estimate. But overall, this approach of relative units of measure for the effort will also work with other scales. It is the ratio that matters, not the actual numbers. For instance, some teams are using T-Shirt sizes instead of story points for relative estimations. They’re literally using the scale of t-shirt sizes when estimating the backlog: M, L, XL, etc.
History of Story Points. When Story Points appeared
Let’s try to figure out what the genesis of Story Points is, where Story Points began, and the reasoning behind it. It turns out that the notion of story point was first introduced by Ron Jeffries, one of the cofounders of Extreme Programming methodology (XP). So, the history behind the Story Points is the following.
Once upon a time, Ron Jeffries and his team were involved in a new payroll project. It was a huge project, the scope of which was known upfront and comprised around 400 stories (work packages). The team spent a couple of days estimating each of the chunks in a number of working weeks that it would take to complete each particular story.
But later, in the course of the project, the team decided to introduce another unit of measure, so-called ideal days. By ideal day they meant a day when the team was not distracted to any other activities, when nobody participated in any meetings, and nobody was off. It was kind of a perfect working day for the developers. Unfortunately, these mythical ideal days had never happened.
So, they started tracking how many ideal days worth of work they got done in two or three-week iteration. In other words, they calculated how many ideal days they had got in fifteen real working days. It turned out that it took them 2-3 real days of work to get done as much as they could do in one ideal day. Basically, it was the ratio of three between the days they planned to spend on the particular piece of work and the days that they had really spent. And that was really confusing to the management, who kept asking what was wrong with the estimations.
In order to respond to this management request, the team decided to introduce an interim measurement unit, which was a point, committing that it took them three days to make a point. The story point really started to tie this relationship between a made-up number of the ideal days and the actual elapsed time.
Later story points evolved and became a relative measure of the effort needed to complete a particular task.
Story Points versus Man-Hours
As we can see, story points emerged as a response to the shortcomings of estimation in man-hours. However, we can’t tell that story point estimation has become the new standard of estimating software development projects. This is because estimation in story points has its drawbacks. Let’s take a look at the pros and cons of estimating in both man-hours and story points.
Man-Hours Estimation Pros and Cons
Story Points Estimation Pros and Cons
Use cases of Story Points and Man-Hours
Based on both estimation techniques’ advantages and drawbacks, I would suggest the following applications for each of them.
Use estimation in Man-Hours when:
1. You’re putting together a business proposal with a high-level estimation and project budget as the main point.
When you take part in a tender or when you’re justifying the project initiation at your company, the project budget is probably the most critical item that will be of interest to project sponsors or your potential clients. In this case, the easiest way to calculate people’s costs is to multiply working hours to be spent by the hourly rate and then sum them up. Don’t forget to use the PERT estimation technique, though, when estimating each work package. This allows you to take uncertainties and risks into account.
2. The project is focused mainly on support activities.
The critical constraint of a support project is usually the estimated time of completion (ETA). It means that the customers or project stakeholders are willing to know how soon their request will be completed. If you tell them that you need 5 story points to complete the request, it won’t make much sense to them. So, in this case, estimation in hours is an obvious choice.
3. The project is short, or only one person is working on the project.
If the project is short, let’s say up to one month long, or if there is only one person assigned on the project, there is no reason to overcomplicate the estimation by using story points. In fact, all the benefits of story points are offset in the mentioned cases because there is no such thing as team velocity (or even team) in this case.
Use estimation in Story Points when:
1. You’re involved in a long project from scratch with a clear vision, but possible changes on the way.
If you’re starting a new project from scratch and know that there is a general roadmap, but the details will be refined on the go, story points are the right choice for estimation units. In this case, you can confidently apply the traditional Scrum approach, breaking the scope into iterations, changing priorities and requirements if needed over the course of the project.
2. The project is dedicated to the constant improvement of the existing product.
When you have a working product that was built earlier, which needs a constant improvement of functionality, story point estimation is also applicable. Usually, in such cases, the product team also has some roadmap for improvements, which means you can plan your iterations ahead and track all the necessary metrics. The only big difference between the kind of project mentioned here and the project built from scratch is that you need to allocate some capacity for unplanned activities (for example, production fixes or technical debt) in each Sprint.
As you can see, there is no universal standard measurement system for the estimation of software development projects. The type of the project is the only aspect that impacts the choice of the estimation technique. There are certainly a lot of others, such as organizational policies, previous experience, etc. Please, write in the comments how you approach the problem of choosing the project estimation technique. How do you decide in which units you will estimate the work?