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 in an agile Scrum community. The TeamPoolz team wants to route all the power output to shed some light on this and other metrics.
How?
By introducing an educational business intelligence tool showing a good set of metrics for team, product, and organizational scope.
In the eyes of management, I will not repeat numerous articles explaining how Velocity is used to command and control but will instead try to explain how you will use it to contribute to an overall company outcome.
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 support the team’s planning sessions successfully, 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 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, giving 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 used mainly for balancing effort during a sprint planning session.
I do not buy the idea of using Velocity for mid to long-term planning. 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 discuss this in more detail.
To generate the Velocity History chart, there is only one measurement:
Accepted Story Points
You can get one at the sprint review event – at the end of the cycle. The Product Owner should review user Stories even during the sprint. 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 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!
Update: In early 2022, a product reboot has happened, which pivoted the product much more towards setting goals (OKRs) but still has its roots in teamwork, metrics, and evidence-based management.