The hidden problem that is killing your Scrum team’s productivity

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp

Over the past decade, agile has taken over as the most popular way to develop software. If you were to suggest a waterfall model today, where each phase of a project has a well defined deliverable, you will almost certainly be laughed at. Agile, and in particular Scrum, is perceived by many as the ultimate way to develop software. It allows companies to quickly react because of its short delivery cycles, ensures a good fit with users through the product owner and provides excellent management information with burn-downs and story points. So why is it then, that many experienced Scrum teams are moving away from Scrum?

Measuring productivity

In Scrum, productivity is measured in Story Points. A Story Point is not a static value, like a meter is. Rather, it is a value that can differ between teams and therefore, first has to be gauged. Gauging is done continuously in Scrum, by comparing the feature that must be implemented, with a previous feature.  If a previous feature was 5 Story Points and the team thinks this feature is slightly bigger or more complex, the estimation can be 8 Story Points for example.

Teams try to keep feature sizes small, because small features are easier (i.e. more accurately) measurable than larger features. In addition, they generally use a Fibonacci-like estimating scale that helps both with keeping small estimates, as well as preventing arguments whether a feature is 10 or 11 points; the only options are 8 or 13.

After a while, the team will get statistics on the number of Story Points they can deliver during a sprint. Every sprint the team estimates the features that the product owner wants, they pick the ones that fit in the sprint and they start developing. It’s a pretty simple system.

Management tools

Through Story Points, Scrum also gives great management tools. Because the team is working with Story Points each sprint, a chart can be made that shows all features that need to be delivered in a certain release. Releases usually cover multiple sprints, and contain a set of features that the product owner wants. Once all features have been estimated, the chart will show whether the release can be shipped on time, or is expected to be delayed. This is calculated based on the number of Story Points that the team handles each sprint, and gives the chart a downward characteristic. Hence the name burn-down chart.

The burn-down chart is actually a very interesting tool that provides a lot of value for management and makes some of the discussions at board level a lot easier and more insightful. After all, not everyone understands software development and the intricacies, so having a nice chart that shows the progress at a short interval is worth a lot.

Improving performance

No matter how interesting the management tools are, they cannot take away the fact that software development does not lend itself well to precise estimation. Inevitably, someone will want to ‘increase productivity’. Meaning they want the software to be delivered on time, with all its features. And, depending on your perspective, this is where Scrum either shines … or shits the bed.

The product manager goes back to the team and says: “Team, we have to improve our productivity.”. The team, understanding well that this increase in productivity cannot jeopardize quality or budget, will feel pressured. Ultimately, they want the product owner to be able to show an increase in productivity, but they don’t want to sacrifice quality or work double the amount of hours. So, in order to double the productivity, they simply estimate features to be double the size in Story Points.

Story Point Inflation

Now, you may think this will be noticed. But in reality, it doesn’t. That is because this inflation of Story Points happens gradually, over a larger span of time in practice. As management keeps pressure on the team to be more productive, the team will feel they need to be more careful in their estimations, leading to higher Story Point counts. This will in turn show a higher number of Story Points delivered in a sprint, translating into a perceived increase of productivity. At management level, it looks like the team has indeed increased productivity.

This problem happens in many Scrum teams. Those teams that are more experienced have therefore started to look to other agile methodologies, such as KanBan. It doesn’t mean Scrum is a bad methodology, or that other methodologies are better. What it does mean, is that you should know the weakness of the methodology you choose. In case of Scrum, it’s Story Point Inflation.

Get started for free and experience the power of the Triggre platform.

By signing up for your free account, you agree to receive e-mails from Triggre.

By using our site you agree to our use of cookies to deliver a better site experience.