Thursday, 31 January 2019

Weighted Velocity: An Approach to Addressing the Impact of Planned and Unplanned Leave on Yesterday’s Weather

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 normalized estimation approach. However, for most of my large enterprise clients the need to estimate for the purposes of planning is a practical necessity and SAFe’s normalised estimation is a useful tool, when used as intended.  Given this, I have chosen to put the debates about the evils of estimation and normalized story points to one side and instead focus on how we might be able to help 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 a sprint or program increment.

When planning agile teams generally use “yesterday’s weather” to predict their velocity/capacity for the next sprint (or sprints 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 last sprint’s velocity is the best predictor of next sprint’s velocity. Where team velocity is the total story points delivered by a team (planned and unplanned work).  Of course, this approach does not take into account that a team's capacity is not equal from sprint to sprint, as it is affected by both planned and unplanned leave.  I have observed that ARTs tend to solve for this by re-setting their capacity every sprint using SAFe’s normalised estimation approach - which drives me batty!

Frustrated by the misuse of SAFe’s normalized estimation approach, 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 sprint 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, too. (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 (ARTs) 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 sprint. 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 sprint planning when they reach the end of the sprint, perhaps as part of their sprint 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 variance occur I suggest the team has 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.



3 comments:

  1. Can you share more resources or insight into this idea " we all know there should be not be overtime on an agile team!!". This is the first I have heard that there should not be overtime on an agile team...

    ReplyDelete
    Replies
    1. Agile Manifesto: Agile processes promote sustainable development.
      The sponsors, developers, and users should be able
      to maintain a constant pace indefinitely.

      XP: http://www.extremeprogramming.org/rules/overtime.html

      It is one of the main principles of Agile, not doing overtime so that the team can have a sustainable pace and not get into saturation

      Delete