Here are 2 stories…
Manager (to team): “I would like you to become more effective!”
Team: “No problem, we’ll just double our story point estimates, then we will complete twice as many points next sprint.”
What will the manager answer?
A. “Great! I’ll say that to my boss”
B. “Well, that really don’t make you more effective, only the metrics changed”
“In my team, we use estimates. After the sprint, the manager says: “You did not deliver all you promised”. The team feels bad and decides to increase the estimates as a buffer, to ensure they won’t take too much into the next sprint – without telling the manager. The team completes everything the following sprint and the manager is happy. The next sprint the team silently increase their estimates a bit more, only to complete a higher amount of points at the end of the sprint. The SM and the Manager is really impressed because this team now completes more points than any other team.”
Story 1 is one I made up (kind of), and story 2 I was told by a friend of mine, when he wanted my opinion on the topic “Storypoint inflation”.
Putting it as simple as in story 1, most people will believe B is the best answer – without hesitation – and will not accept the suggested solution to just devalue the story points. But story 2 seems to appear more often, even though the only difference compared to story 1, is the speed of story point inflation. So why does it happen?
Before I elaborate on that I will say that I see indications of a company not having an agile mindset – They might be “doing agile” rather than “being agile”. That will be wrong for me to conclude with my limited knowledge about their situation, and it will be naive to think that a few words about “Storypoint inflation” and “Commitment” could solve their challenges. Having said that, I still believe that these few words on the topic, could be a first small step, to changing the mindset in an organization like that. And here is how I would go by it as a ScrumMaster.
- Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.
- Ensuring storypoint estimates are for the team, and the team only!
- Fulfilling the managers need for measuring effectiveness.
Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.
If the manager, the product owner, or a team member, or anybody else for that matter, treat sprint commitment as a “promise of delivery”, “commitment” is not used as intended. In software development we never build something that we have done before. Therefore I find it difficult to believe that we can foresee everything, and that makes it hard to make a “promise to deliver”. Though, it should still be the goal to deliver. We should have the intention of delivering, including considering and talking about what makes it possible or not.
Theres a good read, of why “Commitment” was changed to “Forecast” in the 2011 Scrum Guide. Commitment vs. forecast on Scrum.org
If you think this means, commitment is no longer needed, you might want to read this as well: Scrum values – Commitment from Scrum.org
Coaching the team and people around the team to use “Forecast” instead of “Commitment” (as a promise to deliver) can give the team the space they need to focus on developing good software. If the manager is still in a need to know about progress, and when the team can deliver, Invite him/her to join a demo, so he/she can see the product. After all, the primary measure of progress should be working software.
Ensuring storypoint estimates are for the team, and the team only!
Storypoints is NOT a metric for measuring effectiveness, and it should NOT be used for reporting to management. I can’t state this clear enough. Nevertheless, this seems to be the case a lot of places. I think it´s because storypoint estimates are numbers, that are easy to work with, if you come from a traditional way of working with projects. But this way of using storypoints, causes some uintended problematic behaviour. So, what to do about it?
Storypoint estimation is a tool for the team. It serves two main purposes. It is a tool to get a good dialogue going in the team, and it is a tool for forecasting. Everybody around the team must understand that the estimates made by the team, is for the team only. Any interferences with the estimate and/or estimation process from someone outside the team, is in risk of resulting in storypoint inflation.
Does a team even need storypoint estimation? No! If the team have sufficient dialogue, and is able to make forecasts to managers and other stakeholders, the team does not need to do estimates at all. One way of finding out, if the team needs it, is by stop doing it, for a fixed timebox, and then evaluate. If not all aspects are covered during team dialouge, it might be a good idea to use Storypoint estimation.
Fulfilling the managers need for measuring effectiveness.
So now we have made the manager and other stakeholders understands that a “forecast” is something we aim for, which is not the same as a promise. The team are now estimating storypoints only for the purpose of the teams own dialogue, and as a tool for forecasting, and only if they benefit from it themselves. But the manager still needs to report to his manager how effective the team is working and now we’ve just left him hanging there. Some might argue that is should not be needed for the manager to know this, or that managers are not needed at all, but I’ll bet you will have a hard time explaining this to the manager. And if we cannot change the organisation, we have to deal with it somehow.
So, what if the manger asks: “How effective is the team at this point?”, and the team could answer “We’re at 87%”, Would that work?
My good friend and ScrumMaster colleague, Lars Buhl Schamaitat, made this short presentation, and if you can relate to some of the challenges in this post, this might be of your interest. Enjoy