We have new teams working on scrum and they estimates all the points of a several ammount of stories. But, at the beggining, they have no reference of how ammount of points could be delivered in two-week sprint.

We see at the end of the sprints that not all the points are being completed. Near to the end, the team is overhelming, and the quality is being sacrified just for deliver on time.

I want to know if this kind of KPI makes sence in scrum environment, and if not, how can we assure the team are being as productive as they normally are?

  • 1
    What metrics did you use to measure "normal productivity" before switching over? This is important, especially if those metrics aren't effective. – Erik Aug 12 '18 at 8:07
  • Before scrum, we just measure the deliver on-time, rather than productivity itself. The team set the due date of each task and they must complete it in the agreed time. – Josbel Luna Aug 12 '18 at 14:45


Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work.

Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you should measure the Scrum Team's effectiveness (including the effectiveness of the Product Owner!) in meeting the Sprint Goal each iteration.

Sprint Goals

The goal of a Sprint is never to do lots of work, complete N stories, match historical or projected velocities, or achieve 100% utilization of resources. If you're managing to these sorts of metrics, you're violating core agile and Scrum principles.

In Scrum, the Sprint is an ephemeral time box that is filled with Product Backlog Items that:

  1. collectively express a coherent Sprint Goal, and
  2. all fit within a single iteration.

This focus on a central coherence is not discretionary. It is a foundational element of formal Scrum. The Scrum Guide's Sprint Planning section says:

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Velocity's a Forecast, Not a Target

Velocity is a commonly-used metric in agile frameworks, but is not formally a part of Scrum. Furthermore, the correct use of velocity is never as a management target or as a measure of productivity. When used properly, velocity should be:

  1. Expressed as a range or trailing average rather than a single value.
  2. Used to estimate team capacity for upcoming iterations based on historical averages.
  3. A sanity check about how much work is too much to be accepted into an upcoming Sprint, rather than setting a goal for how much work the team should take on.

In Scrum, planned work should never exceed the length of a single iteration. Finishing early is great, while insufficient slack will typically reduce flow and throughput.

Don't Measure Productivity with Velocity

While velocity can be helpful in initial backlog estimation, agile release planning, forecasting capacity for the current Sprint, or identifying hidden process problems through trendline analysis, it's most definitely not an accurate measure of productivity at the individual or even team level. It's a planning value, and (to a lesser extent) a detective control for the project.

Velocity is often misused as a management target, and a way to "hold developers accountable." If you're doing this, you're doing agile wrong!

Velocity is a proxy metric for capacity, and perturbations in flow are more often attributable to:

  • process problems such as scope creep, ill-defined user stories, an incoherent Sprint Goal, or a lack of rigor in the Definition of Done;
  • outside or external dependencies such as out-of-band testing or vendor delays; and
  • technical debt accumulated through the project life cycle.

Assuming your team has reached a stable velocity, if velocity suddenly drops then you should certainly work with the team (and especially the Product Owner) to identify the underlying process problems. Once identified, issues can be addressed in a variety of ways including scope negotiation, early Sprint termination, and inspect-and-adapt events such as Sprint Retrospectives.

See Also

  • "This focus on a central coherence is not discretionary" Yes and 'coherence' here need not mean 'directly related to the Sprint Goal' Consider this from the Scrum Guide: "To ensure continuous improvement, [the Sprint Backlog] includes at least one high priority process improvement identified in the previous Retrospective meeting." So if said improvement related to having a new board to track impediments, it is entirely consistent with a Sprint Goal relating to a new software widget because improved visibility of impediments should contribute to satisfying the Goal... – onedaywhen Aug 13 '18 at 13:58
  • ...Otherwise, the development team would be severely limited in what improvements they could pull in from the Retro! – onedaywhen Aug 13 '18 at 13:58

We see at the end of the sprints that not all the points are being completed.

Yeah, this should not happen. Do everything you can to make this scenario very unlikely. For example, pull into the Sprint what would seem to be a ridiculously unambitious number of Product Backlog items (PBIs), with the aim of giving the team the experience of completing a Sprint early: what do they choose to do with this 'slack' time?. A really interesting experiment is to pull just one PBI into the Sprint, with the aim of giving the development team the opportunity to experiment with self-organization: will they 'swarm' to complete the work?

Near to the end, the team is overhelming, and the quality is being sacrified just for deliver on time.

Yeah, this should not happen either. In addition to the above suggestion, get the teams to review their Definition of Done (they likely may share one). Is it rigorous enough? Is it being applied? Can any of be automated? Quality is non-negotiable and zero bugs is achievable.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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