Skip to main content

Average Predicted Velocity & Completion Rate

Last post 01:13 am February 28, 2024 by Ian Mitchell
5 replies
11:48 am February 27, 2024

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?

12:19 pm February 27, 2024

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.

12:57 pm February 27, 2024

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?


01:33 pm February 27, 2024

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.

03:51 pm February 27, 2024

@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). 

01:13 am February 28, 2024

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.