Blog

Tales of the Bizarro Scrum – Assigning Points to Everything

  • Post author:
  • Reading time:4 mins read
You are currently viewing Tales of the Bizarro Scrum – Assigning Points to Everything

Development Team Member: “I’m taking a bio break. I’ll mark that down as 1 point!”

This of course is an exaggeration and I truly hope no team is doing this. However, team members are doing similar things when it comes to estimating using story points, especially when velocity is being tracked by upper management. When this happens, there is constant pressure to maintain the same velocity, or even worse, to increase velocity. This leads to assigning points to bugs, emergency production issues, meetings, trainings, etc., all to keep management satisfied with the velocity metric.

Velocity, if used properly, is a very helpful tool for forecasting. It is not however a productivity metric, and this is where we run into problems. Many managers use it to measure a team’s productivity and then in turn, the team feels the pressure from management, so they start assigning points to everything or inflate the point estimates to look “good” and keep management happy. The minute management puts a spotlight like this on velocity, you lose all ability to properly forecast and velocity becomes useless.

Velocity is supposed to provide transparency on the team’s abilities to deliver on items from the product backlog. However, in any Sprint, there is planned work and unplanned work. As the amount of unplanned work increases, velocity is supposed to decrease to highlight that the team is being distracted by bugs, productions issues, company meetings, etc. This does not mean that the team is not being productive. They are. However, they are unable to focus on high value product backlog items.

For example, if the product backlog contains a lot of bugs, then those should get 0 points, and velocity should decrease to indicate that the team was rushing through things and should slow down to produce better quality work instead of having things pop-back up again a Sprint or two later.

If the team is constantly getting interrupted with emergency production support issues, those should get 0 points, and velocity should decrease to indicate that the team is getting pulled away and prevented from focusing on building high value product backlog items. And so on.

This will reflect the team’s true abilities and velocity is supposed to highlight these issues so they can get addressed at the team level and the organization level. When we assign points to all these activities, we are hiding the “dysfunction” and pretending that everything is fine when clearly there is room for improvement.

Velocity will go down before it will go up. It will keep going down as development continues and the product becomes more and more complex. And it will not magically go up on its own. The only way velocity will go back up is if as an organization and as a team we invest in continuous improvement via learning, pairing, training, automation, etc. Any other results are likely due to somebody “cooking the books” or weakening the team’s Definition of Done.

Remember, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, and “Working software is the primary measure of progress.” Management should focus measuring value delivered and not velocity. Leave the spotlight off of velocity so that the team can properly use it for forecasting purposes.