It’s important to keep in mind that “improving” your team’s velocity does not necessarily mean that there is an increase in the measure of velocity.
That being said, there are some things that generally lead to improved team performance and more consistent velocity measurements. It’s part art and part science. Although these outcomes largely come from gained experience, there are some changes to process that can help.
Improved and more consistent velocity comes from:
- Better teamwork and collaboration
- Velocity as a measurement and agile development as a process revolve around a central unit: The team.
While it’s often tempting to measure the performance of individuals on any given team (especially with regard to productivity), this is almost never helpful. Instead, focus on facilitating better teamwork and collaboration. Find ways to improve communication between members of the team to provide support wherever necessary.
At 7pace, the team uses time tracking as a granular measure for individuals within the scope of an iteration. This allows each member of the team to understand when and where they can help each other to achieve the scope of work they’ve agreed to complete.
One common pitfall for agile teams is how they scope and define user stories.
A fundamental part of this process is the importance of breaking down a user story into its most basic elements. Ideally, each user story should comprise only a small number of story points.
If your team finds that an entire iteration is taken up by only a few large user stories, then it’s easy for an entire user story to be incomplete. This will likely be reflected in a large dip in velocity for that iteration and introduces a lot of uncertainty and extra work for forward iterations.
Continuously work to refine user stories into more granular units of work that can be more easily included and completed within a single iteration.
Part of this process just comes from experience.
As a team works together on the same products or projects for long enough, they begin to improve their estimation skills. While they may have been wildly inaccurate–and inconsistent–in their estimations early, they will begin to improve as time goes on. Keeping teams together is an important part of this learning and growing process.
Keep in mind that velocity is a feedback loop in and of itself. The velocity that a team sets should be based on its history of productivity, not an arbitrary number dictated by management.
It may seem as though one way to improve a team’s velocity is to simply cram more user stories and points into a given sprint.
In reality, this almost always has the opposite effect.
Most teams only count completed user stories when measuring their velocity. That means that any incomplete or partially completed stories will not be included. So, if the scope of work is simply too large to complete within a given iteration, then the velocity will likely suffer overall.
Teams need autonomy to know their own capabilities. Having additional work piled on helps no one. It destroys the process and undermines the design of agile software development as a process.
Lastly, there is often performance to be gained by simply improving the planning or development processes and systems.
Many teams fall into a specific workflow that they use again and again. But, much of the value of agile software development is its iterative nature. This gives you the chance to learn, try new things, and improve your systems.
Use retrospectives as a chance to identify possible improvements and then test them in future iterations to measure their effectiveness.
Keep in mind that processes and systems aren’t necessarily about raising velocity per se. It may be a matter of improving the way that your team estimates or reviews work that’s completed–how it leans.
Velocity on its own is important, but “speed” for the sake of speed shouldn’t be the ultimate goal.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.