Recently, I was having a conversation with one of my friend, I observed that he was looking a little disturbed and asked him what is happening. He said “At work my management tracks team velocity as a performance objective. My team has recently started working on new complex and critical work but team velocity has gone down from what was it before. As it is a critical piece of work, management has provided 3 more people in the last sprint but still, velocity has not improved. On the worse side, it has gone down. I have my annual performance review tomorrow, I am afraid it is not going to be good. What should I do”
I was in a similar situation a couple of years ago and believe me it is not a great place to be in. Before we jump to what I believe a scrum master’s action should be in such situations, let’s discuss the velocity itself.
Velocity is one of the tools for the Scrum Team to self-organise itself. It is an average amount of work that the team can turn into ‘Done’ during a sprint. For example, if a team has delivered 30 ‘Done’ measure of work (story point is widely used estimation metrics, but there are different metrics as well) in 3 Sprints, then
Velocity = Amount of ‘Done’ work/number of sprints i.e. 30/3 = 10
Team Velocity is a helpful tool for the Scrum Team. It helps 3 roles in the following ways:
Development Team: In Sprint Planning to identify how much work they can pull from the product backlog. Generally, the team uses empirical evidence from the previous sprints and creates a target velocity. It also helps teams’ in their own inspection and identifying continuous improvement actions to increase velocity without compromising quality.
Product Owner: In release planning and managing stakeholders’ expectations. He/She uses the historical average to create future projections. For example, if velocity is 10 and there 100 points worth of work then, the Product Owner can apply simple mathematics to come to a figure of 10 sprints to complete the work. However, a good PO will make sure that stakeholders/customers are aware that it is still an estimated projection and will include this risk into his/her communications.
Scrum Master: Velocity gives Scrum Master some aspects that should be made transparent to the team so that they can inspect and adapt. Remember, it is Scrum Master’s responsibility to make the team more productive. Using velocity data, the Scrum Master can build some insights that will help the team to be more productive.
Back to the story- ‘What should a scrum master do’
In my opinion, It is wrong to assume that velocity in the next sprint is going to be equal to the most recent sprint. In the above story, the team has started working on the new work. Their knowledge and experience are not going to be the same as the previous work. A team only gets better with estimation over time. Moreover, it is wrong to assume that ‘more resources means better results’. Generally, for the short term, team performance goes down when team dynamics change. Scrum Master should coach the management about their wrong assumptions and explain the real purpose of the velocity. It is a hard job and qualifies a very famous quote about Scrum, ‘It is very simple to understand but difficult to master’.
When a measure becomes a target, it ceases to be a good measure. — Goodheart’s Law.
Tip: Before using historical values for velocity; ask questions, such as mentioned by Mike Cohn in his book Agile Estimation and Planning.
- Is the technology the same
- Is the domain same
- Is the team same
- Are the tools the same
- Is the working environment the same
- Were the estimate made by the same people
In this section of the article we will focus on, What Velocity is Not
Velocity is NOT a measure to compare teams
Teams are made of different people. No two teams can be exactly the same. There is always at least some level of diversity. For example: If one person in Team A is off sick for 3 days during one sprint. It is unfair to compare Team A’s velocity with Team B even if their combined skill set, capacity, the experience level is exactly the same (very highly unlikely).
Velocity is NOT a promise/commitment of what will be delivered in the future.
Velocity is based on estimates which are guesswork. Teams get better at estimating over time but no-one can perfectly estimate in a complex environment. Such expectations put teams under unnecessary expectations which most of the time is counter-productive.
Caution: Velocity that is based on some ‘guesswork’ resulting from information and knowledge team has about size, effort, and complexity. Planning based on this depends on many factors and should not be considered as a contract.
Velocity is NOT an indication how hard a Development Team is working.
In some organisations/teams; higher velocity is considered as a team’s performance indicator. This sometimes leads teams to alter the numbers or perform overtime/weekend working, which is not a sustainable way of working.
Caution: Never attempt to calculate Individual Velocity
Most companies have got individual performance objectives. Some as part of that try to calculate individual velocity. It leads to behavior that is generally not aligned with the team’s goal. Instead, individuals should be rewarded based on teams’ achievements and how that person has helped others in achieving the team’s goals.
It is NOT a measure of value
Higher velocity doesn’t directly co-relates to a higher value. There are still many factors such as technical dependencies that drive the product backlog orders. There is a reason why the Scrum Guide replaced the word ‘priority’ to ‘order’ from 2010 to 2011 version.
Velocity is a very good tool. But, if not used correctly, this good tool can become a detriment to a team’s morale and can also build some bad practices such as ‘gaming the numbers’. This reduces transparency. Without transparency, inspection can’t be right and the right adaptation can’t be done. In nutshell, empiricism is lost. Without empiricism, scrum fails.
Management’s obsession with ‘Velocity’ can lead to unnecessary stress, overtime, weekend workings, conflicts. This can affect team members’ mental health. Recently UK figures about mental health at the workplace suggest that almost 15% of the workforce experience mental health problems and it costs UK businesses up to £8 billion per year. It is a huge loss. Agile ways of working are about delivering value and make the workplace more enjoyable and happier by having motivated and empowered people.
Velocity is a great tool for a Scrum Team but its wrong usage can create some very serious long term problems and all the possible benefits can go away. Everyone must understand that it is only valuable when it is used only by the scrum team with its intended usage.
On the end note, please share your thoughts and your experience around velocity and its usage.