.png)
Very often I have sat in meetings and watched Developers and PO “fight” over what the team velocity is or should be and how they can’t estimate a particular story as a certain point because it is impacting their velocity. The most surprising encounter was when I interviewed for an Agile Coach role a couple of years ago and was informed that the increasing velocity of the teams was one of the measures of success for the role. The statement got me a little bit confused and I asked for clarity on how it ties to their overall goal. The interviewer struggled to give me a concrete explanation.
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and it is fast becoming a key metric in Scrum. Velocity is calculated at the end of the Sprint by totalling the points for all fully completed User Stories. The Team often uses an average of 3 sprints to arrive at its velocity. While a Team's velocity will oscillate from Sprint to Sprint, over time, a well-functioning Scrum Team's velocity should steadily trend upward by roughly 10% each Sprint. However, it is known for teams to reach a plateau and this is where the Scrum Master comes into champion the team to push up the velocity.
Ever wondered what the origins of velocity are? Early texts (such as Extreme Programming) were generally favourable to measuring “individual velocity”, a practice which fell into disrepute over the next few years. Sometime in 2002, the Scrum community picked up the practice of measuring velocity. Despite no mention of the word in the Scrum Guide, it plays an important role in helping most Scrum Teams to keep process variance in check and to create a basis for short-term forecasting. However, it becomes a problem when it gets in the way of the team’s productivity.
What not to do with velocity
Pitch teams against one another:
There is no meaningful comparison of velocity “between” different teams, since such teams may have different approaches to estimation and the team composition differs. When I worked at a Fintech company some years ago, a Director of Agile would always call out teams they had performed very well at the end of the sprint based on the story points completed and not the value delivered. This increased the defects rate because the focus for the teams was not quality but velocity.
Get hung up about it:
When a team has autonomy, it is in the best position to examine and increase its velocity to optimize value creation. However, in an environment where the push is from the top, it breeds toxins, creates mistrust and demotivates everyone concerned.
Team Performance
Dont use the velocity as a performance appraisal or as part of Key Performance indicator.
How to use Velocity - if you must
Feedback mechanism: Velocity is a key feedback mechanism for the Team and not the Manager or Organisation. It is meant to help the team to measure whether the process changes they make are improving their productivity or hurting it.
Forecasting: facilitates forecasting of how many stories a Team can do in a Sprint. (In Scrum this is called using Yesterday’s Weather.) For forecasting purposes, the average of the last three Sprint's Velocity should be used. Because it takes the team three Sprints to determine its Velocity accurately, it can sometimes be difficult to explain to impatient stakeholders.
Planning tool: By knowing the team’s velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve the desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can forecast the release(s). This could in turn inform the stakeholders when to expect a return on investment.
Wrap Up:
If you don't wish your team to “pad” the story points/estimations, do not force upon them to increase velocity. Instead, encourage them to focus on continuous delivery of value and working software. All you need to do is sit back and watch the velocity increase- if that is a goal.
Coaches should work with the teams to help manage expectations and communicate progress. Some of the ways to keep Stakeholders and Managers in the loop is to invite them to the sprint review and to observe the daily scrum
Leave a comment below and share the blog on your social media platform as some people might also find it useful. In addition, your gesture motivates me to write more. Thank you.