In my experience increasing trend in the team velocity is rarely achieved and/or is difficult to know. This blog was an outcome of my reading the following statement which related with my experience. “While teams will tend to increase their velocity over time—and that’s a good thing— in reality, the number tends to remain stable. A team’s velocity is far more affected by changing team size and technical context than by productivity variations.” from Story – Scaled Agile Framework.

I remember starting to coach a team in the initial stage of my Agile Coaching career. It was a distributed team adopting the Scrum practices and seeing the positive changes it was bringing in on the various fronts. The first change was better Say/Do ratio, getting the Planned stories to Done, with fewer misses.
The team, to start with, was doing high level planning for the sprint, stopping when they had the info on who is working on which stories. It would be the team member volunteering to work on a story or assignment due to the natural fit of the skill set. Quite a few stories were not getting completed.

More detailed planning

As a coach, I influenced them to invest a bit more in the planning and do capacity-based planning. This helped and they could identify several potential issues at the planning stage itself. The first A Ha moment was when the capacity of one of the QA member Rakesh, was almost fully planned for and another QA task came up. The team realized that the Dev may have to chip in, but the QA task in question required a license for a tool that was with Rakesh. So, they did the adjustment of swapping the tasks that required the tool with Rakesh and reassigned the tasks. Fortunately, they could see the benefit at the planning stage itself, and adopted it whole heartedly.

The planning had good impact and they had better Say/Do ratio, it showed up as Went well comments in the retro and resulted in more details being added into the planning spreadsheet that was being used for the sprint planning.

It was exciting and I was looking forward to see the increasing velocity trend which, sadly, turned out to be mythical.
Soon it was Deepavali, so there was adjustment to available capacity. It was followed by Thanksgiving where again we had impact on the capacity. There was shift to the REST API, which required some capacity earmarked for learning. All these impacted the planned velocity itself.
So I saw the dream of increasing velocity trend crumbling, as the planned velocity itself was not consistent. Not that the teams were not doing better. The team capacity was not stable, even with no changes in the team composition.

Stable teams but unstable capacity and capability

First, the number of working days in the sprints would vary, there would be holidays and large organization events. Second, the available capacity of the team members would vary due to leave, being unwell, training etc. There would be changes in the team composition too though not frequent.
There would be changes in the nature of the work, like moving to REST API that would impact the capability and so on and so forth.

The team would be aware of the variation in the planned velocity during planning itself. They would look at the variation in their velocity in the retrospective against planned as well as the past velocity and figure out the reason for the variation – but there would be variations.

I thought maybe in the next project or team I would be able to able see this increasing trend, but that moment never materialized.

So what?

In some time I had categorized the increasing velocity trend as a myth. I did check this out with fellow coaches and found the situation more or less the same. There were exceptions where this trend was visible.
I accepted this fact and moved on, but there was another aspect – leaders or managers of the team would occasionally ask this question to the coach. That was tricky.

How shall we know if we are improving?

I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing “are we improving?”

A simple exercise helped here, in fact I started this with the Scrum Master/team initially, to ascertain that they are doing the right things.

Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to – what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn’t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.

Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.

Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white.

What has been your experience? I am sharing my perspective and would like to hear your views.

Pic: Kelly – Photography (pexels.com)