Speed is a crucial ingredient to all companies, especially startups. The defining characteristic of startups that end up making it against the odds, is their ability to move fast. So what does speed mean for engineering teams? Velocity.
In this article, you’ll learn what velocity means in the context of an agile/scrum methodology and how you can actually improve it to allow your team to move faster and ultimately ship more stuff.
Velocity is a metric that tracks how much work your team was successfully able to complete in their sprint.
This is normally done by adding up all the effort estimates to see how many of these were completed in that time period. As velocity is based on your effort estimates, it requires these to be accurate (it generally takes around 4-5 sprints to find your average).
According to Martin Fowler,
A typical approach is to average the velocity the past three time periods to determine velocity for future time periods.
If your team is faced with new tasks and distractions once the sprint has already begun, your velocity is guaranteed to suffer.
That’s why it’s so important to clearly define the tasks and prioritise them before you begin your sprint. Be consistent when it comes to accepting or rejecting changes from the rest of the company, everyone should be aware of the deadline for submitting ideas and features to the engineering team.
Technical debt is the silent velocity killer.
Developers are constantly under pressure to deliver features faster (hell, that’s probably why you’re reading this article). We all know that this pressure results in shortcuts and assumptions, which are probably necessary at the time. However, it’s easy to forget these concessions and if they’re not dealt with, they turn into technical debt that will weigh your team down.
To optimise for velocity, you need to ensure that your codebase is well maintained. For smaller pieces of tech debt, engineers should follow the boy scout rule, for medium to large pieces of debt you could consider using a technical debt management tool (like Stepsize).
Retrospectives (or retros) are a key part of the agile methodology. It allows the team to identify what went right or wrong in the sprint and how to improve for next time.
As Maruti Techlabs mentions,
The most important benefit is that it cuts through hierarchy and gives equal power to the team members to open up and present their views effectively.
Ensure that these retros happen in a trusted environment, without blame, so you get maximum transparency. The meetings will require time and participation (developer kryptonite combo), but it’s a tried and tested practice that will lead to extremely valuable insights and tweaks that will ultimately speed up your velocity.
A happy team is a productive team. Make sure the team is rallied around a common goal and that they have clear ways of expressing feedback if they’re not happy (like the aforementioned retros).
The work that is done should also feel satisfying, try to bridge the gap between the business side of the company and the engineering team, by, for example, showing how many users started to use the feature that was built in the last sprint (Hotjar is a great tool for visualising this).
Don't forget to cheer for the maintenance and tech debt heroes: the people who refactored this nasty function, fixed that bug, reviewed these pull requests, and ultimately saved the team hours of work by keeping the codebase healthy.
So there you have it, 4 ways to improve your team’s velocity. It’s important to remember that your velocity cannot be constantly increased (you don’t want to end up with inflated estimates). Instead, try to evaluate it periodically and make the changes that you feel will have the greatest impact on the team.