Estimation that is based on Story points is pretty unreliable, but still the Scrum team should complete a Sprint backlog on time - isn't it a flaw in the Scrum process?

  • Where did you get the idea that a backlog represents a money-back guarantee of any sort?
    – Todd A. Jacobs
    Dec 14, 2019 at 22:41
  • Why do you think it’s unreliable? Do you know what’s the point of doing it? When doing so doesn’t help, do you know why? Dec 15, 2019 at 3:12

2 Answers 2


A Sprint Backlog is a Forecast and it can change as part of the sprint when the Development team uncovers more about the work to be done. There is no explicit expectation that the Development Team will always deliver it's forecast or that the forecast can't be changed.

As part of the Daily Scrum:

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.


We also expect teams to become better at slicing their work, at delivering more frequently (even multiple times per sprint) and at dealing with unforeseen complexity. Yet, highly advanced teams will encounter unexpected things and it may happen that you don't deliver what you had planned. That's part of life. Scrum can't change that.

  • I thought that a Sprint is a mini Waterfall project and a Scrum Master is kind of a project manager responsible for completing it on time... Dec 14, 2019 at 21:09
  • 2
    Absolutely not. While a Sprint can be seen as a mini project, it's the Budget and Time and Quality that are fixed in Scrum. The Scope therefore MUST remain variable. Dec 14, 2019 at 21:11
  • 1
    Apart from that, Story Points and Velocity are a complementary practice. Not required in Scrum, but compatible and often combined. See for example the Kanban Guide for Scrum teams on how to replace these with Flow metrics for predictability instead: scrum.org/resources/kanban-guide-scrum-teams Dec 14, 2019 at 21:14
  • Scrum isn't meant to be 100% predictable, but to create many opportunities to act on the reality that our work isn't as simple as we thought it would be. Every daily scrum and Sprint review help the team and the stakeholders to adapt to the reality as it unfolds. Dec 14, 2019 at 21:20
  • 1
    The comment was tied to the sprint. Indeed. Quality is fixed through definition of done. Time through the sprint timebox. Budget through the development team's capacity for that sprint. And while the goal of the sprint is fixed (unless cancelled) the forecast and plan can be changed by the development team (in collaboration with the PO) when needed. Dec 16, 2019 at 8:13

As others have said, relative estimation (story points) is not an essential feature of Scrum, it just happens that relative estimation works very well with an iterative approach to delivery. The principal reason for agreeing estimates during Sprint Planning is to decide which stories can fit into the current sprint - that is all. So estimates don't have to be very accurate, they just have to be accurate enough to determine when the sprint is full.

With a new team or when working with a new kind of problem or technology you may find that estimates aren't very accurate. The team's ability to estimate will usually improve however. As the team becomes more practiced over successive iterations they should get better at estimating things and so the velocity should settle down into something more predictable. Past velocity is used as a guide during Sprint Planning to decide when the sprint is full.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.