Better Performance using Time-mapped Story Points Estimation in a Scrum Environment

If you happen to work in Tech and join a new team, there is a good chance they are using Scrum to organize their working process. Or they use their own tailored version of Scrum (often just for the sake of using Scrum). Scrum itself and Agile in general are a discussion on its own. In this article, I want to talk about a major problem that arises during “estimation” which tends to be done at planning meetings at the start of the sprint to estimate the duration of all tasks that a team would like to complete during that upcoming sprint. After describing the problem at hand, I will suggest a solution which I managed to apply in a real-life project.

The Problem with Story Points Estimation

Estimation is typically done by giving each task a number of “story points”. I presume you know how that works so I will not explain the process from scratch here. In any case though, there is a particular set of story points each member can choose from, which roughly follows the Fibonacci sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, and the coffee card. Some teams also use so-called t-shirt sizes or crude hours for estimation, but using modified Fibonacci is the most common.

When I was learning Scrum for the first time, I was explained that the estimation was a team-specific thing. Because even if multiple teams use modified Fibonacci, they might have a totally different understanding of what a particular number of story points exactly denotes. We do not know how long it will actually take for a task to complete. We only know that the tasks at hand are in some way relatively related to one another, which is the idea behind using Fibonacci. Task 1 may take X time, and we can estimate that task 2 may take Y time. Task 3 may then take double the amount of time for X, so its duration becomes 2X and task 4 is estimated to take around the same time as task 1 and 2 combined, which is X+Y. Still, we do not know how long task 3 and 4 will actually take to complete and since we don’t even know for sure how long task 1 needs, how can we know for any tasks that are based on the duration of task 1? Consequently, if we are wrong with the estimation of the duration of task 1, we will be wrong everywhere.

Furthermore, some teams try not to estimate the duration, but instead they estimate something different, such as the “complexity” of a task. What does complexity mean? Well, that’s pretty complex (pun intended). I could give you a definition, but the point is that everyone has a different idea about complexity and in the end nobody knows what it really means. And more often than not, not everyone may even fully comprehend the task because they had been working on other stuff. So you simply don’t know what you are estimating, and you also don’t know how long a task takes to complete. Also some teams try to estimate the “difficulty”. At least that is a clearer term, but then you still don’t know how long the task takes to complete. After all some difficult problems might not take much time to solve once the solution has been found, whereas some easy problems may take quite long, for example if there is a lot of tedious and repetitive work. In other words: Difficulty and time do not correlate, so difficulty should not be used for estimation.

We can summarize the main problem of estimation to one sentence: There is no anchor. And a corollary is that there is no objectively-measurable performance metric to assess the accuracy of the estimation with respect to our expectation of how many stories we can complete within a sprint, and how long they take.

And let me make clear: Estimating tasks in a Scrum sprint is about its duration. Not its complexity. Not its difficulty. Not its priority. It is the duration in time! Because after all, we want to know how much work can be done within a sprint. So the only relevant factor here is time.

Solution: Time-mapped Estimation

Truth to be told, there is no hard scientific data on any of the ways of doing Scrum. You never know how things would have gone if you had used a different methodology to develop your product. Yet I will argue that this solution is going to come with significant benefits that may improve overall team performance, individual performance and provide an objectively-measurable performance metric that can be used to track progress and be understood by people outside the team.

Without further ado, I suggest the following breakdown:

Let us go over the breakdown and assume we are starting a new project with sprints that last two weeks, or 80 hours, assuming each day has 8 working hours. If there would for example be one public holiday in the sprint, the sprint duration would be decreased to 72 hours. In any case, one story point is equal to two hours of work.

Now, if you are a developer who is dedicated full-time to the project for 40 hours per week, then you should have 80 hours of work to do during the sprint, or 8 hours per day on average. Although doing 8 hours of work would be ideal, you will practically only work around 6 hours. The remaining two hours are usually lost because of meetings, tracking progress, team affairs, helping out colleagues, toilet breaks, booking your upcoming business trip or various other bureaucratic rituals. Let us call all that overhead, that should take up around 25% of your working time.

Thus, it is expected that you should have around 60 hours of actual work per sprint, or 30 story points. In practice, that may be a range of 28 to 32 story points. You can then for example take task combination of 8 + 8 + 5 + 5 + 3 + 1 = 30 story points, respectively requiring 2 days, 2 days, 1.5 days, 1.5 days, 1 day and 2 hours = 8 days + 2 hours, with the remainder of the time to be used for overhead.

Of course, your amount of overhead may depend on your role. A project manager with lots of necessary meetings with clients, other teams and company-internal affairs may have an overhead of for example around 50% and could put in only 40 hours of actual work during an 80-hour sprint. But for most developers, in my experience, an average overhead of 25% is normal. I recommend taking that as a baseline and for the sake of simplicity do not change it unless you have a very good reason to do so.

If you work part-time, e.g. 80% or only 4 out of 5 week days, then you will only have 64 hours that you can work during a sprint. Assuming your overhead is 25%, you have 48 hours that you should do actual work which translates to 24 story points.

So whether there is a public holiday, part-time work, or maybe you have an external training for two days, you can calculate for yourself how many hours you will be working and how many story points are expected from you to fulfill during the sprint. This is your capacity, which you should make clear to your team during the planning. The actual amount of story points assigned to you is your workload and the amount of story points you completed is your performance. You should make sure that your capacity matches your designated workload at the beginning of the sprint, and at the end of the sprint your performance should match your original capacity.

If you perform less than was planned, then there is underperformance. Maybe there was a good reason, such as being sick for a day, in which case your capacity should be retrospectively adjusted. On the other hand if you completed all your tasks before the sprint is over, you can take up additional ones and possibly achieve overperformance.

Benefits of using Time-mapped Estimation

Now that we understand how time-mapped estimation works, let us discuss the various benefits that this approach offers, contrary to the “normal way”.

Firstly, it becomes much more clear how long a task will actually take to complete. Also we can use an analogy to describe the duration to both developers and non-technical people such as a project manager or client. If a task has been assigned 3 story points, everybody understands that it will be a full day of work: 6 hours of actual work and 2 hours of overhead. When going over a task list during a sprint, you can estimate much better how much work still has to be done and how long it will take. It will improve communication and also allows stakeholders to make an agreement on how many story points are supposed to be completed in a larger timeframe and how much capacity is required for that.

Secondly, because time is measurable, you get quick feedback on how well the estimation was done. Maybe we planned one full day for one task, but needed two full days. Or maybe it went quicker than we thought. After a whole week, we get feedback for the sprint as a whole. Over time, the team will be able to make much accurate predictions on its duration without nitpicking over a few minutes here and there. Complexity is subjective, but time is not.

Finally, it will become much easier to track both the team performance and individual performances. If the overall performance matches the total team capacity, then it means that the team is doing a good job. If the performance exceeds the team capacity or if the performance is lower, then this is an indication that the whole team can do better when it comes to scheduling task estimations.

Potential Drawbacks of using Time-mapped Estimation

Although “drawback” might not be most accurate here, there are in the end both advantages and disadvantages for both team members and for example project managers, compared to each other.

Apart from measuring team performance, the system also allows for measuring individual performance. Over time, assuming constant full-time capacity with 25% overhead, each team member should complete 30 story points on average per sprint. It can then occur that a team member has a structural deviating performance, where we can speak of either underperformance (e.g. < 25 points instead of 30) or overperformance (e.g. > 35 points instead of 30).

In the case of underperformance, it could be that this team member is more junior than the rest and understandably needs more time to finish the tasks compared to the others. Then you may choose to have his acceptable performance bar reduced to a different amount of points. Or your team member might simply not perform up to the standards and you may decide to remove him from the team. In that case, you can back that up with evidence of him not completing enough story points during sprints. The other way around, if you as a team member are told that you are not performing well enough, then you can present evidence that your performance always matched your capacity. So in the end it is a double-edged sword.

With overperformance, there may be the case where someone is overperforming because he is a senior and understandably needs less time to finish a task. Or he is not a senior yet and may make for a good promotion candidate if he is performing better than expected.

Finally, the double-edged sword also applies when discussing the overall expectations with stakeholders such as your client. The client can now much better assess if the team is performing as expected, and may find evidence that you are not holding up to the standards. But if you are performing well, you can also make your case that you have fulfilled the client’s expectations.

Conclusion

Making estimations when you are part of a Scrum team can be tricky because often it is isn’t clear what exactly you are estimating, even if everybody knows what the task entails. The problem is that there is no anchor and no objectively measurable metric to track performance of both the team and its team members. This makes it difficult to make sure that the project is on track, and possibly intervene when a deviation from the expectations is discovered.

By applying Time-mapped Estimation, we map our story points directly to units of time. Here, 1 story point is equal to two hours of work. We take into account that in a 40-hour working week only 30 hours are actually used for work and the remainder is lost due to necessary overhead such as meetings. This way, it becomes very clear how much time is required to complete a task and we also get feedback on whether our estimations were accurate. Over time, we should be able to perform the best possible estimations and achieve a consistent trackable performance.

By introducing trackable performance, there are both benefits and drawbacks. Overall, it becomes much easier to track the overall team performance but this could also be used against a team when working with nitpicking stakeholders. On an individual level, the performance can also be tracked much better. This can be used both to the advantage and to the disadvantage of a team member.

Despite the drawbacks, I find that the benefits should predominate. It is eventually in everybody’s interest to be productive and perform well, so nobody should have a reason a complain. For any ‘lazy’ people, the trackability may also give a positive stimulation to put in performance and those who are afraid of being picked on by their manager are now given a tool to provide evidence of them having lived up to the standards.

To recap: