Our organization has a number of Scrum teams working on various projects. Some exhibit much higher velocity than others. Unfortunately, some of the teams with low velocity run the risk of not being able to complete high priority work items in the product backlog. Management is considering whether to replace team members with more experienced and/or skilled members. For example, replacing a mid-level developer with a more senior developer. However, some believe the team is understaffed and that we should add more team members. As consultant coaches, what are some things we should consider? How should we advise our client?
How can we increase the velocity for our Scrum team? First, and most importantly is to make sure we understand the problem. Although ostensibly the problem is low velocity, we should first review the way velocity is being measured, and then compare that to other throughput measurements for this team and other teams. If Story Points are being used, compare the number of Story Points delivered (velocity) versus the number of items delivered (throughput), and compare both numbers to those of other teams. Also, are Story Point estimates updated at any time after initial estimates are recorded? We have observed situations (especially for a new team) where an item was estimated very high but was delivered much faster and easier than expected. This “mis-estimation” would skew the velocity upwards. Of course, the same thing happens in reverse even more frequently, due to “optimism bias” (see Thinking, Fast and Slow by Daniel Kahneman). Due to these factors, it is entirely possible that what we have is a mismatch of expectations rather than an actual case of low velocity. Expectation management is a critical piece that many IT workers miss. Even accomplishing the remarkable feat of landing on the Moon may be viewed as an abject failure if management expected a Mars landing.
Assuming we have done our due diligence and are convinced that there truly is a need to improve velocity, there are several options available to increase the velocity of a Scrum team, including process improvements, tooling improvements, scoping changes, and staffing adjustments. In order to determine the most appropriate thing(s) to change, we should first consider our circumstances and ensure we are addressing the underlying reasons behind the current level of throughput. Even if we are extremely confident in our analysis and recommendations, we should still proceed scientifically, ensuring we have accurate baseline measurements and performing “safe to fail” experiments that are quantitatively measured to prove their effectiveness. We should also be aware that some changes take time, so the results may not be immediately visible.
Since we are talking about a Scrum team, an optimum size all else being equal is generally agreed as being between 3 and 9 team members (depending on many factors outside the scope of this article). We should consider:
Assuming none of the above issues sticks out as a root cause of slower performance, there is ample time left in the cycle, and the team is amenable and not already full, adding a senior team member or two could indeed be helpful. In our experience it is best if the team participates in the interviewing process. We do not recommend replacing a team member except in the case where a team member is widely recognized as a problem by the other team members. On a Scrum team, incompetence or apathy is immediately noticed by all team members and should be addressed quickly. Assuming proper HR procedures are followed, replacing such a team member with a more senior and committed person is usually welcomed by the team.
In summary, when looking into how to increase velocity for a Scrum team, we should keep in mind that there are many different possible root causes for “low velocity” on a Scrum team, and adding or replacing team members is disruptive and may even be counter productive. We should first consult with the team: perform our due diligence and root cause analysis. We may need to make some small experiments to validate our hypotheses. Finally assuming the team is amenable, we may add or even replace team members if it makes sense.