How to improve a Software Team’s Velocity?

How can we increase a team’s velocity?

Well, that’s an odd question. I don’t think you can really!

Though, If by “increasing team’s velocity” you mean to “Finish” more story points, then that’s another wrong question!

Velocity depends on two thing: one is Definition of Done and second is Definition of a Story point. So if you change any of those definitions your team velocity changes even though you haven’t changed anything on the “Things” your team actually delivered.

One thing that happens very often is, you define something for a team as their velocity and just stick to it.

Example: If in a team you have defined a 1 Story point as somthing one developer can finish in a day, and you have 2 week sprints, and you have 4 developers, then your team velocity is 40 and anything under this number is considered “Bad” or at least bad planning or maybe people thing it means team has had distractions. And if a team of 4 developers, delivers more than 40 points, it is a productive team!

Well none of that above paragraph is true or even mean anything!

First of all, things a team delivers depends on so many things, like the developers expertise in that subject matter, their seniority, their motivation, requirement clarity, distractions, and much more.

Also one thing you need to make sure is that, you gotta change the Velocity after each sprint based on the previous sprint! if you delivered 30, then that’s your velocity. You shouldn’t go back to 40 again! cause it is possible that you just be 10 points short again!

At the end of the day, the Velocity is a metric for the team. The business shouldn’t really bother about that. And increasing it doesn’t necessarily mean increasing business. What we need is a continuous effort in increasing the total business value delivered each Sprint/Release.

Important Question:

What does it mean if all teams deliver equal story point each sprint to the maximum of their velocity?

Does it mean they are all productive, all estimates where accurate, and they delivered equal business value? NO!

One team might be more motivated, more experienced, and deliver the same tasks in half the time the other team delivers, so the less motivated team will double the estimates, and will actually deliver “half business value” compared to the more motivated team, though statistically they both delivered equal story points.

Improving Team’s Productivity

So with all the rant I went on around Velocity, I hope I was able to change your perception just a little bit.

I have put together as list of things that can improve a team’s productivity (Actual Business value that they deliver, even by a tiny bit)

Less distraction for developers by the stakeholders. Everything (bugs, escalations, requirements, new features, etc) should be handled and planned by the BA or the QA analyst in the team.
Effective communication between the developers and developers and BA and QA for any questions or better understanding of the requirements . Developers need to learn it is OK to ask questions and ask them as early as possible to do something faster and be more productive (this might sometimes contradict the previous point, which you might need some tools/ways to facilitate both).
Clear back log and more organized grooming sessions. Good solid user stories so developers are not blocked or confused by looking at it. Though with agile some people say you don’d need to document as much! but I think the user stories should be clear enough so developer can implement them if the BA is on holidays.
The team needs to have a “Continuous Improvement” mindset. Having effective retrospective meetings at the end of each sprint will help with one. The team should try and resolve at least one issue from the retrospectives every sprint.
The development team should look for opportunities to do automations/scripts if there are tasks that are being done manually. All teams have stuff that they do manually. Like localization, reports, code merges, builds, deployments, etc.
Allocation of interruption buffer for bugs, support in every sprint. Maybe 0.5 day per developer per week?
Make the projects that are delivered visible and recognized. Have some recognition for the team after every major project delivery. Let the team know the impact of the work they did after the fact. If we cannot tell that is a problem to solve.

Example: A development team spent 3 months developing a new sales tool. did you let them know how much business impact that had in the company’s sales? Did you celebrate that project’s effort with that team and everyone involved in delivering it so they get excited and motivated for their next challenge?)

Try to avoid multitasking.

This list obviously goes on. so please feel free to add yours in the comments and i will update the post with yours.

Some notes on Motivating developers in the team

In general I believe the key to improve productivity in the team, and deliver more business value is to motivate people in the team.

Sisyphus syndrome is common in agile teams, because team member feel like they never reach after a number of sprints! We need to make sure there are milestones that we recognize the work they do.

People need to feel:

Achieved something (by everyone noticing and recognizing they finished something.
Fulfilled, by enjoying the journey throughout the sprint.

Let people know what the impact of the wok they did was on the business.
Recognition after each project can be in forms of a gift card, geek T-Shirt, a post card, or a mug!

When/if you are going out for lunch or drinks after each sprint or each project delivery, just mention that, it is for the recognition of their contribution to the project delivery.

This list also obviously goes on. so please feel free to add yours in the comments and i will update the post with yours.

Some Interesting math

If we had a team of 15 developers
We improve productivity of each individual by 5% (by some of the above suggestions, or other ways to think about)
For an average developer 5% improvement means they focus around 15 to 20 minutes more than usual every day, (yes just that little more focus). Note: they don’t need to stay in the office 15–20 minutes more, just focus 15 minutes more instead of checking cat videos online.
The overall team will gain around 5 hours of more developer hours in a day
And in most of North America, that means we have hired another developer, that will cost us around 100,000$ if not more!

Cheers!