One of our dev managers came to me to ask how from a reporting perspective we can easily account for random low velocity sprints?
When I dug deeper into the question the problem they are trying to solve is that for the most part team velocity has been pretty constant (which is good) but every once in a while there will be the odd sprint where velocity is drastically lower than the others.
If they go digging they can normally discover that there were lots of vacations, or other commitments that contributed to this, but time and energy is being spent to gather that information from sources outside of Jira.
What they would like to know is if there is a method we should be using to surface this information more easily.
As a stop gap measure they have been making notes of these types of anomalies in the sprint goals so that upon viewing the sprint report for a given sprint that information is easily accessible.
My question to all of you, is this the best way to handle this? Is there a plugin/addon that would give us what we are looking for? Or is there something else I have completely missed in the out of the box functionality?
Putting my agile coaching hat here, so might not be the answer you are looking for but food for thought.
Why isn't the reason for the change in velocity not being surface during the sprint retrospective? Most teams would surface this information there and not have to pull the data from a collection of tools.
If vacations and holidays are occurring during a sprint, the teams should be adjusting their sprint commitment (how much velocity is committed to) during sprint planning. The team could flag to management the change in velocity before a sprint starts and why the team changed the commitment.
I agree with you there. I asked similar questions, and the response I got was not around ensuring the team reduced what they committed to, because they did, the report shows a lower overall velocity for a given sprint and that is what needs to be accounted for. As I'm typing this out, I have a feeling that I need to talk to people higher up the chain as this may be an edcuation issue vs a lack of functionality in the tools issue.
I think you are right James and good luck with that education.
For others in this situtation, this is what I do as an external coach:
Sometimes I'll meet management halfway by getting the teams to record their retrospectives in confluence. If management doesn't trust what the team is saying in the retro or sprint commitment I might raise the subject of trust, and how going for hard metrics over what they are saying will indicate a lack of trust and then demotivates the team.
@Alan Parkinsonthis just came up today in our retro. except it was related to holidays. We're using a fixed two-week sprint structure. We were starting on a Mon. and finishing on the following Fri. I'm now having a Sprint review and closing the sprint on Fri. AM and immediately starting the new Sprint right afterward so they now cover a full two weeks. Jira shows weekends in the burndown but doesn't seem to account for holidays. Is there a way to show that in the reports or does it just have to be common knowledge that a holiday occurred and we should be adjusting the overall velocity in an earlier planning mtg.?
We are still trying to determine the overall team velocity as we still aren't very good at Story Point estimation so this question is for future reference for me.