One of the Scrum Masters I was coaching had brought up the issue of the team members not clued into/or caring much for the team’s velocity.
The team was very capable, the team members would participate passionately in the Sprint Planning, try to ensure that they are able to meet the forecast/commitment. Would listen in to updates in the Daily Scrum intently. They would help out each other when required, at times on their own volition or when asked by the other. Only issue was that they were not bothered about the velocity.
The velocity was fluctuating and one day, as I was passing by their bay, I heard the Scrum Master tell her team, “Look guys the velocity is fluctuating, what will the managers think/say?”
I stopped and gave a pitch – the team should be more bothered about the velocity than the managers, the velocity is owned by the team first! The concept of the team owning the velocity, was something that had not settled in the minds of this fairly new scrum team. I ended by saying that if managers do ask you a question on the velocity, you need to demonstrate such in-depth understanding of why it is so, that the managers walks away feeling assured that the team knows what it is doing.
In the following weekend happened to watch “Drishyam” on the TV, it was a repeat watch. What caught my attention was how the protagonist make the rest of the cast live the story/situation and immerses them in it.
The scrum team at work was doing well in making use of the burn down chart and the physical task board, pondered on how the same can be done for the velocity.
Next day I was discussing the velocity with the Scrum Master, I casually mentioned the movie, the Scrum Master herself had seen the the movie. I asked her how she can make the team live the velocity, bring that up to the same level as how they have adopted the burn down chart and the physical task board.
After some thinking, Scrum Master concurred that the velocity chart was not reflecting the true velocity, due to stories being carried forward from previous sprint and/or to next sprint. This was OK considering that they were starting to adopt Scrum. The team was looking at flaky data as well as it not being consistent was a dampener.
Two items emerged, one is at the start of the sprint, Scrum Master clearly states how many story points were carried forward and how much was taken up this sprint, so the team has a clear view of the velocity. This is captured in a mail too.
Another was to revisit the velocity at the retrospective, the Scrum Master added a link to the retrospective notes/action items, that showed the velocity chart with a brief note on how many story points were actually done, calling out story points carried forward to/or from the previous sprint, and reasons for it.
The team not looking/owning the velocity was a point of discussion in the retrospective, and one suggestion that emerged from the team was that the velocity chart and the call out, on why the velocity was what it was, being done by the team members on a round robin basis. The involving of the team members on a round robin basis, worked like a charm, and in the subsequent sprint planning, thoughts on improving the velocity emerged naturally.
The team was very enthused and one of them was eager to be asked about the velocity by his manager, so that he is able to wow/surprise him with the response. He looked forward to this every time he came across his manager and eventually ended up updating the amused manager on the velocity of the team, on his own.
A small tweak made the team – live and own the velocity.