At the start, you predict a velocity for your team and it works really great. The team delivers awesome increments and the velocity keeps increasing. But suddenly there is a slump. Velocity goes down and you have no clue about it. Been in this situation? Here are 3 primary reasons why the velocity slumps and what to do about it.
1. Maintenance increases proportionally to Delivery
When you started the project, the slate was clean. Nothing is delivered yet to the users. The team had the luxury of focusing on their work at hand and deliver great products.
But as the deliveries are sent and the users are playing with them, many things happen.
- Bugs start appearing
- Users see some things don’t work the way they want them to
- Additional requirements come up and so on…
It takes time for developers to go through and decide on these maintenance activities. Also, time is spent on fixing the bugs and implementing agreed enhancements.
So the developers have two additional tasks in hand :
- Continue to develop software
- Maintain the delivery that is already sent to the users
Depending on how you measure the team’s velocity, this is one major reason for the velocity slump.
How to handle?
The best way to handle this situation is by strategically including such maintenance activities in your velocity calculation. Any value delivered by the team to users must contribute to velocity. In this case, such maintenance activities add a lot of value and help in the final acceptance of delivered product.Keep your #Agile team motivated and prevent complacency from setting in Click To Tweet
2. There is complacency in the air
One of the common reasons for productivity decline is complacency within the team. They are energized to start with but as time moves on, they get happy with what they have achieved. This eventually leads to the demise of “growth mindset” and the velocity takes a hit.
How to handle?
The best way to handle this situation is by maintaining a vibrant environment.
Keep the team motivated and encourage them to achieve more. The purpose is not to avoid celebration or undermine their current achievements – but to set the bar consistently high.
3. “The Last Mile” problem
Another problem that can impact the velocity is what I call as the “last mile” problem.
Velocity calculation normally considers complete-complete work, that is, developed, tested and accepted by the users.
As time goes on and more stories are taken up, the acceptance conditions get more relaxing or incomplete. So when it comes to user demonstration, the non-acceptance rates go up. And, this has a direct impact on team velocity.Last Mile problem that leads to non-acceptance of work by users causes velocity slump #agile Click To Tweet
How to handle?
Never compromise on the quality of user stories. Product owners or business analysts must release the stories for development only when they are considered complete in terms of structure and content.
You may wish to go a step further and have quality checks in place for user story definition. It can be withdrawn later when the team matures.
So to summarize…
A slump in velocity is common once a team gets going. Here are 3 common reasons why it happens:
- As deliveries are sent to users, the maintenance activities kick in and take up a considerable time and focus out of product creation
- Complacency sets in the team once they are happy with what they have achieved
- “Last mile” problem is another reason for the slump, where the non-acceptance rate increases due to poor construction of user stories
Did you ever notice a velocity slump in your team? What were the reasons and how did you handle them?