Project estimation is a tricky task that requires a project manager to be as accurate as possible. Any deviation upward or downward is undesirable. If you deliver the ready product later than planned, you will annoy the client. If you finish faster, the clients may doubt your competence to assess the tasks.
The teams can avoid time frame deviations by switching from absolute to relative values, namely from hours to story points. This is what we did in our projects. With the help of story points, we shortened the planning time and provided the customers with more precise deadlines. In this article, we share our experience and advise how to explain project estimation units to clients.
What Are Story Points?
Let’s start from the beginning and try to figure out what the story points are. Story Point (SP) is a unit of project estimation developed according to the Agile methodology. Unlike hours and staff-hours, this unit is not an absolute value and does not reflect project implementation time. Instead, SP helps estimate a specific task’s complexity, work scope, and possible risks. Based on this data, we set a deadline and share it with our clients.
Significant SP advantage lies in the objective appraisal, which is not tied to a specific person. When we use working hours, the estimation varies depending on the performer. For example, a senior developer may accomplish the same task twice as fast as a junior. With SP, this is not the case as we estimate the task itself and not the person who will implement it.
How is it achieved? First of all, thanks to teamwork. The project gets divided into user stories, and each team member asses them with SPs. If participants give different ratings to the same problem, we discuss it and choose the most relevant number. If an agreement cannot be reached, we opt for a bigger value.
The more SPs the story gains, the harder and longer it takes to complete. When all tasks are estimated, the project manager distributes them between sprints. Which stories will be completed earlier and which later depends on the project specifics. The main thing is to combine the user stories to use the sprint time on peak efficiency.
How To Assign Story Points?
There are several techniques to assign SPs to a user story. All of them are based on the Fibonacci series, which assumes that each subsequent number is the sum of the previous two. You can use the Fibonacci sequence as it is, estimating your tasks with 0, 1, 1, 2, 3, 5, 8, 13, 21, etc. or opt for 0.5, 1, 2, 3, 5, 8, 13, etc. number sequence, which is more typical for Agile project. Another way is to choose one of the methods below. They are also based on a relative assessment but slightly differ by the accuracy.
Benchmarking
You take one user story as a standard and assign any number of SPs to it. All subsequent stories are ranked relative to the base story. For example, if you give twice as many points to the task X as to the base task, it means you should work doubly hard to perform it. This method helps you quickly estimate the task implementation speed as you roughly understand the base “weight.” However, it is not always easy to determine the weight of a problem in such relative units, especially for large user stories.
T-Shirt Sizes
Using this method, you evaluate user stories with T-shirt sizes, such as XS, S, M, L, XL, etc. The smallest size indicates the easiest and fastest-performing task, the biggest — the most challenging one. This method provides a less specific difference as for the complexity of the backlog items compared to benchmarking. For example, the difference between L and XL is hardly recognizable and can be understood differently by team members. At Softensy, we use this method to quickly differentiate tasks at an early stage.
Ideal Time-Frame
Here you set the ideal number of hours or days needed to perform each user story in a project. Remember, the perfect time frame should be realistic, but it does not show the actual time need for task implementation. Later, you will have to translate the ideal hours to the real hours anyway, considering all the time losses. So, perfect time units act as an analog of SPs. This method is good because it is more specific. It is easier to estimate the time than an abstract point. However, this assessment is often subjective and does not coincide with the real capabilities of the team.
How To Estimate Time With Story Points?
Calculating in story points is nice for internal needs. However, your customers will be somewhat confused if you provide the project estimation in SPs. At Softensy, we set a deadline in hours and suggest the estimated release date. We show how long it will take to implement a specific feature (usually in the min-max range) and its cost. Our time estimation comes from the previous assessment in SPs. Some might argue that we do double work, but it is not so. SPs allow us to prioritize tasks quickly. Afterward, it is not a big deal to calculate the time of implementation. Moreover, having a background in SPs, we can easily change the time frame depending on the circumstances.
To cut a long story short, let’s see how to translate SPs to hours. Here is an example.
Example Of Project Time Estimation Using Story Points
Imagine you have a project that weighs 100 SPs with two developers working on it. The first developer’s work scope is 60 points, and their speed is 1 point per 2 hours. The second developer’s work scope is 40 points, and their speed is 1 point per 3 hours. Based on this data, we can calculate the project implementation time. To do this, we multiply the SP number by 1 SP execution time. The general calculation formula looks like this:
PT = Nsp * t,
where
PT is the project implementation time,
N is the total number of SPs,
t is the time needed to finish 1 SP.
Considering that we have two developers with diverse tasks and velocity, we use the formula twice — separately for each developer. Next, we sum up the values and get the final project implementation time. Here is what we get:
60*2 + 40*3 = 240 (hours)
To give the client an even more accurate estimate, we calculate the number of working days required to complete the project. In theory, we need to divide the total number of hours by the working day’s length — 8 (hours). But in real life, developers don’t code bell-to-bell. They spend time on meetings, discussions, and coffee :). Therefore, to provide a realistic time frame, we divide the project time by the number of so-called productive hours. Based on our experience, this number is 6 (hours) a day.
Now, let’s compose the formula of project implementation time in working days.
Nwd = PT / Nph,
where
Nwd is the number of working days needed to implement the project,
PT is the total number of hours to complete the project,
Nph is the number of productive hours in one working day.
Finally, let’s put our values into the formula to determine how many days the project will take.
240/6 = 40 (working days)
How To Update Deadline?
What if circumstances change? For example, a new developer comes to the project, or a third-party service rolls out a major update? In this case, you need to reestimate the deadline. With the SP approach, it is easy to do.
Let’s imagine a situation when a task is passed to another developer who can complete it faster. Let’s say 1 point per 1 hour instead of 1 point per 2 hours. To recalculate the total project time, we place the new value into our formula. Now the calculation looks like this:
60 * 1 + 40 * 3 = 180 (hours)
Translating this value into weekdays, we get the following result:
180/6 = 30 (days)
Or another situation. To implement a project, we need to integrate with a third-party service, for example, a payment provider. After evaluating all the risks, the team estimates the task at 6 SPs. But when devs get access to their API documentation, they realize they need more time and overrate the user story with 9 points. Thus, the total weight of the project changes to 203 SPs. If we assume the second programmer receives plus three points to their task, the project implementation time would be updated to:
60 * 2 + 43 * 3 = 249 (hours)
or
249/6 = 41,5 (working days)
Conclusion
Story points help quickly prioritize the backlog items and identify the most time-consuming tasks in a project. Although SPs are relative values, they are easily converted to hours or days to provide a customer with a project estimate in standard measurement units.
At Softensy, we have recently started using SPs but already felt this method’s benefits. The biggest pro is a significant reduction in planning time and flexibility in setting deadlines. Working with SPs, we can deliver a more accurate estimate in a shorter time. Also, we can show why the deadline changes if such a situation arises.
This article was originally published at Softensy.
