.svg){kind=small}
What are you searching for?
In IT project management, being able to accurately determine the development team velocity is one of the key skills. Since I have not been doing this for such a long time - about 2 years, I constantly try to study different nuances of this issue. I set myself 2 goals - to assess as accurately as possible the team velocities and best practices that allow to increase it.
In IT project management, being able to accurately determine the development team velocity is one of the key skills. Since I have not been doing this for such a long time - about 2 years, I constantly try to study different nuances of this issue. I set myself 2 goals - to assess as accurately as possible the team velocities and best practices that allow to increase it.
I began to study this question after one unpleasant case. We started working with a client who wanted to develop an online wallet application. My task was to determine the team velocity, on the basis of which it would be possible to compose a roadmap for the project and calculate the amount of time to launch MVP. Since this was one of my first experiences, as you might have guessed, team velocity was somewhat underestimated. This led to an ever-changing decision timeline, which finally led to the launch of the project 1 month later and, accordingly, to a dissatisfied client.
Therefore, I want to share with you what a team velocity is, how to calculate team velocity in agile, how to calculate team velocity in scrum and tips for improving the velocity of a team.
Let's start with the basics - team velocity definition in IT projects.
Velocity is a measure of the ability to turn a product backlog into a workable feature over a period of time or a certain cost. Velocity is one of the key metrics in Scrum teams. It basically helps to understand what amount of work the team can deliver during the defined period of time. This metric can be measured in man-hours, number of tasks, history points, or any other unit of measure of work.
Given that velocity is a conditional indicator, it is easy to play with it, inflate and deflate it. By equating velocity with performance, you create a “distorted stimulus” to optimize velocity through quality software development. Whether consciously or not, teams will try to demonstrate an increase in performance by increasing velocity. If such a goal is set, then velocity will become proportional to the performance. But teams will start cutting corners to deliver functionality faster. In turn, this will lead to increased technical debt, and the product that teams are developing will become more and more fragile.
1. By calculating the team velocity, you can track the dynamics of increase or decrease and identify possible performance problems in individual teams and individual employees.
2. BIt is possible to predict the potential workload on employees and the company's ability to fulfill orders in a certain volume within a deadline.
3. With the ability to improve plant maintenance, it is possible to compare performance before and after the introduction of innovations.
4. A personnel incentive system is established, thanks to which the work of all employees is improved.
5. By analyzing team velocity calculation, you can determine the nature of the factors that negatively affect the quality of work. This, for example, is a working day in which there is no break, equipment breakdown or poor management. Working day fixes are being made to improve the analysis.
Answering the question how to measure agile team velocity, usually the team takes some guessed amount of story points to the sprint. But it should not be fully random. Let’s start with the explanation of the terms we are going to use.
Thus, the User Story describes what the user wants to achieve with some action, that defines the key functionality of the system. User story does not have to be very specific, as each user story should be followed by at least one or a list of acceptance criteria.
Acceptance Criteria, in turn, is the list of requirements that should be met to consider the user story as completed, they define the scope of the user story. Acceptance criteria give a better understanding of how the story should work and how it should be implemented.
To start with, the user stories should be written together with acceptance criteria, so that the team understands the scope of each story. Acceptance criteria should be clear to everyone. Well-written acceptance criteria help to avoid misunderstanding between the development team and stakeholders’ expectations.
The easiest way to start team velocity estimation of the user stories is to select the smallest one in the product backlog and assign to it the smallest story point value, for example, 1. Comparing other stories to this one and to the other already estimated ones, the team can assign story points to the user stories. Quite common to use the Fibonacci sequence in the estimates here: 1, 2, 3, 5, 8, 13, 21, etc. As the Fibonacci scale is not a linear one, but exponential, it helps the teams to give more realistic estimates, as in practice, selecting between 8 and 13 is much easier than selecting between 8 and 9. The best practice here is to define the highest amount of Story Points that the user story can have. If the team considers the story too complex to have the highest defined story points assigned, then the story should be divided into 2 different ones.
One of the most popular methods to estimate user stories is planning poker. First of all, the team should understand the story. The product owner (or business analyst, or any other team member who is responsible for user stories) gives the team an overview of a user story. After the team is discussing it, ask questions. In planning poker team members vote with the cards for how many story points they would like to assign to the user story. All cards should be revealed at the same time after everybody has voted. If the thoughts differ, the team members should explain their position. The voting continues until the team gets to a consensus.
The team should try to decide how many stories (story points) they can complete within the Sprint. At the end of the Sprint, the team looks at how many story points were completed, meaning they are meeting the ‘definition of done’ of the project. The team starts to understand better how many story points they can handle during the Sprint. But one Sprint is not enough to understand the velocity.
It takes several Sprints (usually 3-4) to start understanding average team velocity, which can be used for planning. It may take even longer for some teams and difficult projects.
Average team velocity should be revisited regularly. The team can improve their work over time, thus recalculating average Spring velocity is important for better understanding the achievements of the team.
Moreover, the team starts to estimate better over time, when they get to know the project better. Also, it is wrong to assume that more people means higher velocity and better results.
An increase in velocity does not always mean that the team starts working faster. That is more about better teamwork, smarter solutions and approaches to the problems, better decisions, in general, the team may learn from their own mistakes and start doing better and smarter over time. Also, the team starts to know their domain better. All of this should result in velocity improvements over time if everything goes well.
Velocity cannot be used to compare teams, as all the teams are different. It also says nothing about how hard the team is working. Velocity is more about efficiency. Velocity should be treated as a team thing, not as an individual one. Below we have compiled a list of how you can improve scrum team velocity.
It helps the team to work together and collaborate better. If the team members feel that they are not alone, but working as a team, that makes them work efficiently, they understand better that they are responsible not only for themselves, they are responsible for the team results, in general. That is a great motivation factor.
The team should understand the end goal we want to reach, not just the small scope of it that is included in the Sprint. The team should see the full picture to feel the impact.
One person cannot work at 2 tasks simultaneously, and switching between a couple of tasks makes the work less efficient, meaning that less disruption leads to better results.
This includes too many meetings, too much documentation, reports, etc. Nobody likes unnecessary conversations, not needed reporting, which is usually a waste of time and energy of the team. Thus avoiding it can help improve team efficiency.
Micromanagement shows a lack of trust in the team members, which simply demotivates the team. Thus, we believe that building work relationships on trust is the best approach.
The team needs to understand all the processes really well to avoid inefficiency.
The team should regularly work on it, to avoid risks and quality problems in the future.
This will help to reduce the fixes, refactoring time, and increase productivity.
Don’t forget to give time to the team to generate ideas, help others, collaborate well.
At the Geniusee team, we monitor team velocity at every stage of product development. For my part, I, as a manager, constantly monitor this indicator and try to analyze changes in team velocity throughout the project. For each project, I have my own report on the team velocity.
If my team has completed multiple sprints, the team can forecast release and product completion dates and plan future projects more accurately by reviewing the velocity report. Based on the velocity of previous sprints that the report illustrates, I accomplish the following goals:
As a conclusion, I want to say that based on my own experience, through trial and error, I made sure that velocity is a key feedback mechanism for the team. It allows you to assess how the implemented process changes have affected the effectiveness of its work. And although the performance of a team can vary from Sprint to Sprint, on average, well-functioning Scrum teams have a stable increase of about 10% per Sprint. I hope you understand how to estimate the team velocity on the project and what you need to do for increasing scrum team velocity.
