Team stability

Updated: Mar 12

Let me start with a statement – based on my 20+ years of experience:

The Team is like a nuclear reactor – it can create enormous power output resulting in god-like outcome – electricity in every home! Or, it can leak harmful radiation to destroy not only the team itself, but the product also, taking the company to a nuclear waste dump.

Do you have good facilitated processes in effect to reap the power?

The team velocity must be the most misused metric ever in an agile Scrum community. We – the TeamPoolz team – want to route all the power output to shed some light on this and other metrics.


By introducing an educational business intelligence tool showing a good set of metrics for team, product, and organizational scope.

I will not repeat numerous articles explaining how Velocity in the eyes of management is used to command and control but will rather try to explain how it will be used to contribute to an overall company output.

The team must be using User Stories and Story Points (or Ideal Days) for this metric to have any meaning at all. I find it hard with current tooling (JIRA, for example) to successfully support the team’s planning sessions, but that is another story.

By maybe a little provocative title “Is your product team stable?” there is a deliberate intention to send a message about the possible causes for deviations that happen at each sprint cycle. Some of them are non-predictable, like a team member getting sick or non-avoidable like some of the team members taking leave, while some are signs of pulling team members ad-hoc to other projects or bad facilitation practices at sprint planning. In Agile Tools, you will be able to set a comment for each sprint which will give some context to a viewer and semi-intelligent reports. In general, the Velocity history is not a very important metric, especially not if used as one of few or even the only one. It is a team-level metric mostly used for balancing effort during a sprint planning session.

I do not buy the idea of using the Velocity for mid to long-term planning as that would mean having a product backlog refined to a great level of detail for every product backlog item to be in a Definition of Ready state. In one of the upcoming posts about Backlog Health, we will touch on this in more detail.

In order to generate the Velocity History chart there is only one measurement:

  1. Accepted Story Points

You can get one at the sprint review event – at the end of the cycle. User Stories should be reviewed even during the sprint by the Product Owner. That requires User Stories to be small enough to go through the develop-test-fix-test cycle. In Agile Tools early Beta the input form for Velocity History looks like the image below.

Each metric, there are six of them at the time of this writing, will contribute to the Ability to Innovate score of the organization. Currently, all six contribute evenly, but you will be able to set a weight on each metric in later releases. When enough configuration tweaks will happen, Agile Tools will be able to offer empirical data for each industry for you to select instead of guessing the best configuration.

Agile Tools wants to be a digital coach empowering and guiding teams and organizations.

Take good care of the reactor core temperature!

Stay tuned, stay lean!

#AbilitytoInnovate #KPI #metrics

25 views0 comments

Recent Posts

See All