- SAFe Training
- Choose a Course
- Public Training Schedule
- SAFe Certifications
- Advanced Scrum Master
- Implementing SAFe 6.0
- Leading SAFe 6.0
- SAFe 6.0 Lean Portfolio Management
- SAFe 6.0 Release Train Engineer
- SAFe 6.0 Agile Product Management
- SAFe 6.0 for Architects
- SAFe 6.0 Scrum Master
- SAFe 6.0 DevOps
- SAFe 6.0 Product Owner/Product Manager
- SAFe 6.0 for Teams
- SAFe 5.1 Advanced Scrum Master
- Agile Marketing with SAFe
- SAFe 5 for Government
- SAFe 5 Agile Software Engineering
- SAFe Micro-credentials
- Leading in the Digital Age
- Agile HR Training
Weighted Velocity: An Approach to Addressing the Impact of Planned and Unplanned Leave on Yesterday’s Weather
Updated September 2024 to reflect SAFe 6.0 terminology.
Over the past few years, much has been written and tweeted about the evils of agile estimation (#noestimates). There has also been much consternation amongst agilists with respect to SAFe's approach to creating a shared basis for story point estimation. However, for most of my large enterprise clients, the need to estimate for the purposes of planning is a practical necessity, and SAFe’s shared basis for estimation is a useful tool when used as intended.
Given this, let's put the debates about the evils of estimation and shared story points to one side and instead focus on how we might be able to help agile teams and Agile Release Trains (ARTs) become more predictable by improving their approach to forecasting using velocity, where velocity is defined as the number of story points delivered by a team or train in an iteration or planning interval (PI).
When planning, agile teams generally use “yesterday’s weather” to predict their velocity/capacity for the next iteration (or iterations in the case of SAFe’s PI Planning). The idea is that yesterday’s weather is the best predictor of today’s weather. When applied to agile, this is taken to mean that the last iteration’s velocity is the best predictor of the next iteration’s velocity. Where team velocity is the total story points delivered by a team (planned and unplanned work).
When planning, agile teams generally use “yesterday’s weather” to predict their velocity/capacity for the next iteration (or iterations in the case of SAFe’s PI Planning). The idea is that yesterday’s weather is the best predictor of today’s weather. When applied to agile, this is taken to mean that the last iteration’s velocity is the best predictor of the next iteration’s velocity. Where team velocity is the total story points delivered by a team (planned and unplanned work).
Frustrated by the misuse of SAFe’s starting capacity for new teams, I started to play with the concept of weighting velocity to improve the accuracy (not precision) of team and train planning and forecasting. I have come to call my approach weighted velocity. It is a way of adjusting velocity information so that it more accurately reflects capacity. This entails collecting the attendance of data for a team or ART and expressing it as a percentage of the team's normal capacity.
For example, if a team usually has 8 full-time teams members and one was on leave for 5 days of the 10 day iteration then the team percentage attendance would be 93.75%, e.g. 75 days/80 days = 93.75%. I then take the velocity for the same team (or ART) for the same period and divide it by the % attendance. For example, if the velocity for the given sprint was 45 points and the percentage attendance was 93.75% then the weighted velocity would be 48.
This approach can also be used to address the impact of working overtime on velocity as well. (Before all you agilists out there go on the attack, we all know there should not be overtime on an agile team!! and I tell my clients this all the time, but sometimes these things still happen…) For example, the team has 8 full-time team members, and they all came in for a half day on a Saturday. The team would have attended 84 of 80 days, making their % attendance 105%. If the velocity for this sprint was 50 points. The weighted velocity would be 48 (i.e. 50/105%).
By always weighting the team or ART's velocity, we remove the variation caused by planned and unplanned leave, providing a more realistic view of yesterday’s weather for planning and forecasting. Perhaps more simply, we are reverse engineering what the velocity would have been if the team had been at full capacity (100%) for the iteration. Of course, when using weighted velocity as yesterday’s weather for planning purposes, I suggested taking an average over 4 or 5 sprints, then adjusting the number down for any planned leave using the same percentage of attendance approach used above.
I have also found weighted velocity to be exceedingly useful when building cost per story point models, but that is a topic for another blog!As a side note, on the topic of improving the fidelity of estimations, something else I have always found useful is asking teams to reflect on their estimations from iteration planning when they reach the end of the iteration, perhaps as part of their iteration retrospective. What I ask teams to look for is where they feel there was significant variance between the initial estimate and the actual effort involved in completing the story. Where these variances occur, I suggest the team have a discussion about why they think the estimation varied (i.e. what did they learn through the delivery of the story) and how they may be able to use this learning in future planning sessions.
.jpg)
Order on Amazon Now!
Get the book from Amazon now!
Categories
Popular Posts in October
