Once you start to understand Agile development and Scrum methods, you will definitely encounter " Velocity ". It represents the sum of all story points that the R&D team can complete within an iteration cycle; it is often used as a measurement benchmark to assist long-term work estimation and iteration planning.
A few years later, when I was a manager of a team of excellent software engineers, I realized that "velocity" was very flawed when it was actually measured. It is also because of this that I was able to find the real and correct R&D effectiveness measurement index.
01 Why is "speed" not useful?
Let's start with the rate calculation formula:
- Actual Rate = Total Points Completed / Number of Iterations
- Expected Velocity = Total Points Estimated Generated / Number of Iterations (Estimated Story Points are the number of Story Points added to an iteration)
In management practice, most teams will choose "actual speed", so this article also revolves around it. So, what are the specific disadvantages of the actual rate in use?
1. Unable to display floating space
The actual rate cannot numerically show the fluctuation of the actual workload of the R&D team. The following are the story point statistics for two teams with the same point definition in each of the four iterations:
From the results, both teams have a velocity value of 20, but can we say "both teams can complete 20 points of work in one iteration"?
It might work for the second team, which has a small variation in iteration points (± 2 points), but the first team has a much larger variation (± 18 points). If you only look at the actual rate value, managers can't understand and grasp the stability of the R&D team.
Furthermore, it is impossible to accurately estimate the workload of the story and missions to be developed, or to formulate an expected release date for the epic (Epic).
2. Inability to flexibly adapt to changes
R&D teams and needs change frequently. Member attendance, personnel changes, emergency bug fixes, corporate training, etc. will all affect the actual available resources.
However, the actual rate is calculated based on the ideal average operating capacity of the team . Can the team complete all the stories if members are away during the iteration? How does this affect speed? Can the team also accurately estimate development capacity?
Similarly, if the team welcomes a new member, will the actual velocity increase? Or is the development speed of this iteration actually slower because we need to provide training for new members? Do you need to re-evaluate your backlog? We have no clue about this.
3. Estimates are inherently inaccurate
The reason why managing R&D performance with velocity is not effective is that it relies on story points-an artificially defined valuation that is difficult to reach a consensus within the team. At the same time, it is also difficult for the R&D team to ensure that the point measurement standards across iterations are consistent, which is also the number one problem in current work estimation.
Without estimating R&D effort in a relatively standard and accurate way, it is difficult to maintain a steady rate of development. This not only affects the management of subsequent iterations, but also limits the inspection and improvement of estimation accuracy.
4. Members burn out
Finally, setting a team's iteration goals based on velocity values inevitably leads to member burnout.
I believe that many teams have encountered deadlines and urgent deliveries. In the short period of time when the delivery date is approaching, the members are overloaded with work, working 15 hours a day plus no rest on Saturdays and Sundays, trying to complete all the to-do items as much as possible to achieve the iteration goal.
We don't want similar incidents to happen, but it is undeniable that the team speed in the "Extreme Challenge" state has indeed been improved. So, when planning for the next iteration, can the R&D team accept more work than it does now? In the long run, the workload will definitely make the members exhausted.
Velocity should not be used to set team goals, but should be used by managers to set performance precedents and predict future value.
Since the rate is not feasible, what indicators should be used instead of it for measurement and management?
02 Correct Management Metrics: Commitment Variance
Using Commitment Variance (CV) , it helps to enhance team self-organization and self-motivation. Its calculation formula is as follows:
- PointsCompleted-Total Points Completed : The number of story points successfully delivered by the R&D team in the previous iteration.
- PointsCommitted-Total Commitment Points : The number of story points that the team committed to complete in the iteration plan, expressed as the sum of points added to the iteration backlog.
1. Indicator management objectives
When using commitment variance, the R&D team estimates the R&D effort as accurately as possible and commits to a completion target using the same criteria.
The goal of optimizing commitment variance is to reduce its absolute value to 0 as much as possible; the team strives to complete all tasks and make the burndown chart 0 at the end of the iteration.
2. Interpretation of results
If the value of the commitment variance
- If it is greater than 0, it means that the target has been exceeded. The team can decide whether to increase the commitment value of the next iteration based on the commitment value and the iteration process; or combine iteration review to analyze the specific reasons for overdelivery, such as overestimated story points, unplanned manpower increase, and so on.
- If it is less than 0, it means that the commitment expectation is too high. Based on the current numerical baseline, dissect the causes of overcommitment and readjust in the next iteration.
- Equal to 0, it means that the team can accurately estimate R&D tasks and evaluate delivery capabilities. Keep up the rhythm and go forward!
3. Advantage analysis
Using commitment variance instead of velocity to manage R&D deliverability, the team gets the following gains:
- Combining the actual situation of each iteration, formulate iteration commitments and goals flexibly.
- Correctly define story points and focus on accurate work estimates.
- Properly assess team delivery and set commitments and goals with purpose.
- Align work around self-set commitments to reduce the risk of fatigue in sprints.
For team managers, commitment variance is also of great significance, mainly reflected in:
- Gain a sense of security and confidence by having the opportunity to work with a team on new feature and/or product complexity estimates.
- Provide stakeholders with more accurate estimated delivery deadlines.
- Reassuringly authorize members to self-organize and motivate the team to grow by themselves.
4. Potential risks
Of course, there are some potential risks in using commitment variance management.
-
Self-pressure and involution/friction. Once member(s) link delivery workload to performance appraisal etc., excessive internal/personal pressure, over-promise and over-delivery can arise. Managers need to create a safe environment to avoid internal friction among members; they must also be keen to identify over-commitment in order to maintain the long-term healthy and stable development of the team.
-
Deliberately reduce commitment. Some teams may artificially under-commit or complete only part of the commitment. Managers need to identify the existence of pseudo-patterns to avoid waste of resources.
A small suggestion: You can use the commitment variance to manage the work first. After establishing a relatively accurate estimation standard, try to use the speed to establish a capability benchmark, and build a speed-up buffer on the basis of the commitment variance.
03 Case Analysis
Below we use examples to further explain the practical application of commitment variance. Still the two teams mentioned at the beginning, suppose they now use commitment variance to complete task estimation and capability assessment.
In the above table, the team's "average workload actually completed by iteration" is the actual speed. Both teams had an "average number of story points committed" very close to 22 (± 0.25) points, but actual completions were very different.
The first team, using commitment variance, found that the current definition of "points" did not support correct effort estimation and capacity assessment.
So in the fourth iteration, they adjusted the definition of "a little work" and reached a consensus internally. Because of the granularity of the metric, they gave a commitment of 28 points (although the data shows that they only achieved 12 points in the last iteration).
By plotting the commitment variance trends of the two teams, we can see that optimizing the number of story points is also a process of continuous improvement.
04 LigaAI Summary
Based on the same point standard, Commitment Variance organically combines workload estimation with capacity assessment, and solves the problem of insufficient flexibility and accuracy in rate management.
The management goal of commitment variance is to reduce its absolute value to 0 as much as possible. Don't overcommit and make the team exhausted, but also avoid underestimating commitments, resulting in waste of resources.
(Original author: Michel C; Article source: Medium)
To break the bottleneck of growth, LigaAI will continue to share the experience of building the R&D performance measurement system, as well as scientific management methods of measurement indicators. Learn more about performance optimization and growth, welcome to follow LigaAI@oschina , let's grow bigger and stronger together!
I also look forward to your clicking on LigaAI - a new generation of intelligent R&D collaboration platform to communicate with us :)
LigaAI helps developers set sail, and we look forward to walking with you all the way!