An attempt at estimating a sprint’s Story Points capacity
At StuDocu, getting Story Points right is important. It allows us to plan and prioritise the features our developers will be able to work on in a given sprint. In a software services company, this is even more important: it is the key to be aligned with the customers about what can or cannot be done.
TL;DR
Use this spreadsheet and adapt it to the needs of your team.
Disclaimer
In our development teams, a feature roughly goes through the following states:
- Next Up — no developer is working on the feature yet,
- In Progress — the feature is being developed,
- Pull Request — the code is being reviewed,
- QA — the feature is being or will be tested manually,
- Done — the feature is released in production.
At the end of any given sprint, our goal is not to have 0 Story Points in all columns but Done. We consider absolutely normal to have Story Points left in all states — maybe with the exception of Next Up— , as the opposite would mean that some developers would run out of features to implement by the end of the sprint, while the quality assurance engineers would not have anything to test at the beginning of the following sprint.
In this article, we will go through a solution to estimate how many Story Points can be added to a sprint, be picked up by a developer and flow through the states; not how many Story Points can be added to a sprint and move all the way to Done.
What to take into consideration?
Estimating how many Story Points can be achieved in a given period of time is no easy task. It depends on many factors and metrics — not only of the sprint to come, but also of the previous sprints. To be able to have a guess as close to reality as possible, the most important metric is average velocity (Story Points per day) of an engineer in the team.
Story Points achieved during the previous sprint
To compute this the average velocity of an engineer in the team, it is necessary to know how many Story Points were achieved during every past sprints. To start with, let’s look at a given, single sprint. The number of achieved Story Points depend on:
- how many Story Points were left in each state of your workflow after the sprint that just ended (n), as well as the one just before (n-1);
- how much work your team consider as achieved, in percents, in each state of your workflow.
Here’s an example of computation of how many Story Points were achieved during the sprint n:
The computation goes as follow:
- To each state of the workflow (Next Up, In Progress, Pull Request, Done) corresponds a percentage of work achieved*. For instance, in this example, if a 8SP feature is in Pull Request, the team considers that 50% (4SP) is already done, and that 4SP is yet to do (discussing the implementation choices, fixing the comments, manually testing…).
- We compute the number of Story Points achieved in each column by retrieving what was left at the end of sprint n-1 to what is left at the end of sprint n. In some columns, the result can be negative, but no worries — as the Story Points move right along the states, they will, in practice, always be compensated in the next columns’ differences.
- The total number of achieved Story Points is simply the sum of how many Story Points were achieved in each state of the workflow.
* Note: You should be able to estimate the percentage of work achieved per state of the workflow with your project management tools. For instance, look at how much time, on average, a feature needs to move from a state to another. Then, compare it relatively to the time it takes from the moment it is picked up to the moment it is released.
Average engineer velocity during the previous sprint
To the last metric, only a few need to be added to compute the average engineer velocity during the sprint n:
- the number of engineers who took part in the sprint,
- the number of days in the sprint,
- the total number of days off (holidays and other leaves) the team took.
The velocity of a given engineer is the number of achieved Story Points during the sprint, divided by the total number of worked days (number of engineers times number of days in the sprint minus total number of days off).
Average team velocity
What a Story Point actually is evolves with time — for instance as new developers join — , and the velocity of the team can vary with time — for instance as they get to know the codebase better. For that reason, taking into account only the velocity of the last sprint to prepare the next one is not optimal: an average of the past sprints should give a better idea of the actual velocity of the team.
In this table, you can see a new column called Planned Velocity. This metric will be used in the next section, in order to compute how many Story Points the team should be able to achieve in the next sprint.
Note that the more time passes, the more the team is likely to change. This is why you should find the right number of past sprints to look at — in our case, we are looking at the past six sprints, roughly corresponding to a quarter.
Workforce for the sprint to come
Here are the metrics to mix to be able to plan how many Story Points your team should be able to achieve in the next sprint n+1:
- the planned velocity,
- the duration of the sprint,
- the number of engineers,
- the total number of days off the team planned to take,
- the number of Story Points that were not picked at the end of the previous sprint.
You should notice a few differences with the previous table:
- The Days Off column became Actual Days Off, as we added a Planned Days Off column that can differ — days off that the team planned before the sprint versus days off they actually took during the sprint, including sick leaves, for instance.
- The Achievable SPs column was added — multiplying the velocity with the duration of the sprint and the number of engineers, retrieving Story Points that will be missed because of the planned days off.
- The SPs to add column was added — simply retrieving the Story Points left in Next Up to the Story Points computed in the Achievable SPs.
Important:
Here, we consider that a Story Point can be achieved before the feature is actually done and released. This means that the Story Points you can add to the sprint will not all be done and released; it rather means that they will move along the columns with the other Story Points that were left in each state of the workflow at the end of the previous sprint.
Going further
A few more notes:
- The calculation could be improved by taking into account, for instance, individual velocity and days off. However, at StuDocu, we prefer to favor our team dynamics than individual dynamics.
- If your team velocity is increasing, you can decide to add more Story Points than the calculation suggests.
- If a lot of Story Points are stacking in any of the columns, you can consider adding less Story Points than the calculation suggests. This way, your team can focus on the features that are already being implemented.
- If the Next Up column is emptied before the end of the Sprint, it can be a good opportunity for the engineers to spend time on other tasks: learning new technologies, reading blog articles, proposing code improvements, writing or refining technical specifications for the sprint to come, etc.
Summary
This spreadsheet contains all the formulas we saw in this article. At the end of sprint n, you are able to fill in how many Story Points are left in each state of the workflow, as well as the duration, the number of engineers and the number of planned days off for the sprint n+1 to come. It will automatically give you the number of Story Points you should be able to add.
If you have any suggestions or comments to improve it, feel free to drop me a message or leave a comment.
Thanks for reading!
