Average Predicted Velocity & Completion Rate
Hello dear agilists,
I support a company as an agile coach. I would like to share with you a situation in which we are progressing as Scrum. Before each planning, we calculate our average velocity, determine a forecast team velocity for the new sprint, and add work to the sprint accordingly. However, this team receives work above the average predicted speed in each planning (For example, if the average forecast is 50 SP, the total size of the work received is 70 SP).
And at the end of most sprints, our completion rate remains at 60-70%. They bring up this issue every time in the retro and talk about getting work close to the average velocity for the next sprint. However, they continue to get jobs above this average predicted velocity. They commit to the work after each planning and there are no objections.
Do you think I should intervene with the team at this point as a coach? Or should I remain silent, saying that the team has already committed to this and this success or unsuccess is theirs?
Why are teams receiving work? The teams should pull work from an ordered and refined Product Backlog into their Sprint Backlog at Sprint Planning.
Why are the teams committing to work? At Sprint Planning, the team should craft a Sprint Goal representing a step toward the Product Goal. This Sprint Goal is the commitment, which allows the team to handle cases where the work needed to achieve the Sprint Goal may change over the course of the Sprint.
Why are teams receiving work? The teams should pull work from an ordered and refined Product Backlog into their Sprint Backlog at Sprint Planning.
Teams add work to their sprint backlogs to achieve that sprint goal. Shouldn't it normally be like this?
Here, we actually mostly achieve the sprint goal, but we see low rates of completion of the tasks in the sprint. Is the completion rate really an indicator of how soundly the team is planning, or should we not worry too much about this rate?
I've seen a few approaches. Some teams will only pull in Product Backlog Items that they believe directly relate to the Sprint Goal at Sprint Planning, even if that is still far under their forecast capacity. Once the Sprint Goal is achieved and these items are done, they may consider bringing something else from the Product Backlog or do cross-training or overhead work. Some teams start by pulling in Product Backlog Items directly related to achieving the Sprint Goal first, then fill the Sprint Backlog up to their forecast capacity so that once the Sprint Goal is achieved, they know exactly what they should work on next. I don't see any good reason for the Sprint Backlog to ever contain more work than the team forecasts they can possibly complete during the Sprint.
If the team achieves the Sprint Goal, undone work in the Sprint Backlog shouldn't be a big concern. Being able to craft a meaningful Sprint Goal, commit to it, and achieve it more often than not is the purpose of Sprint Planning. The team shouldn't commit to a body of work.
@Thomas shared a lot of the information that I was going to. His insights are good. However, one thing you said stands out to me.
For example, if the average forecast is 50 SP, the total size of the work received is 70 SP).
Perhaps your problem stems from the fact that you are using story points to determine your capacity. Story points are estimates (i.e. guesses) made at a specific moment in time based upon the information that is available. Once work begins on something, new information usually becomes available. So the original estimate (guess) may not be valid any longer. Read up on how throughput and cycle time are calculated and used. I suggest that you go back over past sprints and look at the total number of items that are being completed. It could be that you are being more consistent than you think. I have found that throughput and cycle time are much better indicators of a team's ability to produce as they are trailing indicators based upon actuals. Story points are leading indicators based upon estimates (guesses).
we actually mostly achieve the sprint goal
You don't mostly achieve a commitment. You either do or you don't. The Sprint Backlog is a forecast of the work the Developers need to do to meet the Sprint Goal, and they should commit to the goal, not to the forecast of work.