Introduction

It is a common practice for many Scrum Masters to commit to the exact capacity displayed in the Jira Portfolio. This is often not the right approach and leads to failed sprints. The simple question is why this happens when the capacity calculations are so punctual?

The rush to deliver more

Product owners tend to push towards increasing the velocity after every successful sprint which looks like a natural reaction to the latest achievements. As the team completed a certain amount of story points last sprint, it is expected that it can complete more the next one. And this is repeated until a sprint fails. This push is kind of urge to test the team’s limits. Our experience shows that this is counter-productive. In the end, it appears that this demotivates the team as they see every future sprint as doomed.

The hectic end of a sprint during a delivery rush

When the team’s capacity is calculated to cover exactly one sprint, any delay or materialized risk is reflected by urging team members to work in a hectic rate at the end of the sprint. This leads to actually delivering less than promised due to the stress that something is going wrong. That’s why this rush at the end of the sprint should be eliminated at all cost.

Let the team deliver more by its own will

The velocity can be increased by adding a 10% of the capacity as a buffer that is used to work on tasks not included in the current sprint. Those tasks are fulfilled in Scrumban mode, i. e. from the backlog in Kanban mode during the sprint. It is used as a risk buffer and also to let the team complete its sprint (or at least the sprint goal) a couple of days before the end. Those tasks can replace a problematic task in the sprint (e.g. when there is an external dependency that threatens the sprint). The 10% capacity will be delivered extra, on top of the planned capacity and this will reflect un-materialized risk, e. g. the risk was averted. In case something goes wrong, this buffer will be exhausted, but the sprint goal and commitment will be met. This extra capacity in Scrumban mode should be monitored and if it goes to 20% for example, it means that it is time to increase the team’s velocity by 10% and still keep the 10% buffer.

Our experience shows that this is the time when employees work without pressure and contribute the most. This makes the increase of velocity possible, at the will of the team, without the urge from outside and with less stress. This way, the velocity increase is natural and desired.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and properly estimate stories in Jira (and not only). It helps in avoiding the Big Rush at the end of the sprint and keeps estimates exact by provoking honesty in story estimations. You can start your first Scrumpy Planning Poker session right away!

Tutorial

The following video shows how to integrate the Scrumpy Planning Poker application with Jira and let it edit and estimate stories on your behalf, quick and easy. Scrumpy Planning Poker saves you time!