Reasons NOT to Use Velocity for Sprint Planning

Sprint planning is the process a team undergoes to decide upon the amount of work it is willing to perform during the next sprint. Scrum teams need to master their capacity to take up the specific amount of work it is able to deliver. The Scrum Master is key to this calculation.

Usually, Velocity is the metric used to define the sprint; this metric calculates the average story points delivered by a single team in previous sprints. Actually, this makes sense, right?: a team that delivers an average of 50 story points per sprint should be able to deliver another 50 during the next sprint, shouldn’t it? The answer to this question is an absolute NO.

Unplanned tasks are a major issue to take into account. An average 50 story points does not mean that the team delivered all 50 story points for the tasks originally undertaken. Mid-sprint change of priorities, stage or production bugs and other unplanned tasks may delay the team and imply additional efforts.

The Scrum Master should know that new tasks are going to come up during the sprint and should bear that in mind during sprint planning.

Reasons for Quantifying Unplanned Tasks

Let’s start by analyzing the value of quantifying unplanned tasks. Ultimately, unplanned tasks are still necessary tasks with high business value, and this is the reason why they tend to be more important than sprint tasks.

Predictability is the main reason why it is important to quantify unplanned tasks. When a team’s velocity is 50 but it delivers 30 story points (with 20 unplanned tasks), that team should agree to 30 storypoint per sprint. The capacity for that team is still 50, but since the team needs to complete 20 story points for unplanned tasks, its capacity for undertaking is 30 instead of 50.

Additionally, there is something else you should factor into the equation. Using the example above, when a team with 50 points velocity allows 20 story points for unplanned tasks, the reason for those tasks to be there in the first place should be analyzed: regular changes in business priorities, undetected production and/or stage bugs, or any other situation causing tasks to appear after sprint planning. The Scrum Master is responsible for reviewing this matter and should work along with the team in order to pinpoint and remedy all events causing unplanned tasks.

How to Measure Unplanned Tasks

An idea to include unplanned tasks into your planning is to use a specific part of the velocity. For example, a team with an average 50 velocity agrees to deliver 40 story points during sprint planning, so as to have a 20% margin for unplanned tasks. This is simple enough and a far more realistic strategy than using 100% of the velocity; but it is only an estimate. Establishing a 20% ratio is arbitrary and does not reflect the actual number of unplanned tasks the team is handling.

If you want to be accuracy-driven, finer metrics are necessary. Using a Google Sheet or Excel spreadsheet, for instance, is a good way to be accurate. By using a simple formula, you can identify which tasks delivered had been originally undertaken and which ones had not (you can find a link to a google sheet with an example of this calculation herein below). In order to use this kind of template, upon sprint planning, you should copy the list of tasks undertaken and, at the end of the sprint, you should do the same with tasks delivered. With Jira, this is very easily done by exporting to HTML with copy paste.

This spreadsheet automatically calculates “story points undertaken and delivered”, so we can know the exact amount of story points delivered within the list originally agreed, and which story points were unplanned for. The average resulting from “story points undertaken and delivered” is the value of reference you should use upon sprint planning.

Conclusion

A scrum team should not only deliver value on a constant basis, but also offer predictability about the amount of work it can handle in a single sprint. This predictability has great business value since it allows accurate planning regarding undertakings with stockholders. With Agile, uncertainties arise regarding date of delivery because tasks are defined on the go with sprint planning. However, if a team delivers 40 story points from the originally undertaken tasks on a constant basis, it can be certain that any deviation from the original path will not have a significant impact on final delivery.

Annex 1

You can access a gdoc to calculate unplanned tasks here. All you have to do is copy the list of tasks undertaken at the beginning of sprint planning and, at the end of the sprint, copy the list of tasks delivered.

Juan Granillo Saizar — Principal Delivery Manager @ Spark Digital (an intive business)