Story Points & Velocity are a sign of an unsuccessful team


Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to measure their work.

Accepted wisdom is wrong!

Reviewers: Steve Porter 

“I used to say Story Points set the Agile industry back 10 years. I was wrong. They set the industry back 20 years.”-Daniel Vacanti

Velocity and Story Points are not Scrum

There are a number of things that we collectively believe are required to do Scrum, and these have been perpetrated by the long-running perseverance of trainers teaching to the lowest common denominator and keeping things as simple as possible. There is the general consensus in the trainer community that folks that attend Scrum training are not smart enough to do anything else. However, if you go have a look at the Scrum Guide and see how many time common things that you believe are mandated in Scrum are referenced:

  • Velocity: 0
  • Story Points: 0
  • Burndown: 0
  • User Stories: 0
  • Original Estimate: 0
  • Bug Count: 0
  • Actual Completed: 0

The answer to all of these searchers is zero! These are complementary practices that may or may not work within the bounds of your organisational complexity, and all of these are an indication to me that your organisations are only just starting its evolution towards agility.

Managing the unknown is hard

It’s ok for a team to start with Story Points and Velocity. There are many things that change when a team moves from the traditional project management practices of the past to the empirical practices of the future, and sometimes we need to pick our battles. One such battle is that of story points and velocity and in fact all of the gubbins surrounding it.

Perhaps you need to appease other parts of the organisation that are not yet ready for change. Perhaps you have a long journey and this is just somewhere to start.

Story Points & Velocity can be a good starting point!

Planning Poker

I am not saying that there is no value in Story Points or Planning Poker. When a team is just starting out they need to keep things simple and iterate towards better outcomes. We often start from typical traditional practices and Planning Poker becomes a good learning point. Story Points use rough sizing as a way to analyze the work and break it down.

Because really, the scores are made up and the points don’t matter. It’s the conversation that is a valuable thing. The shared understanding that the participants get by having some way to know when they don’t understand the same things. That is awesome.

However, agile teams try to use Story Points and Velocity for future predictability and this is a fallacy. While I would be OK with a team using it for a while, if an Agile Team is still using Velocity and Story Points after they have 5 or 10 sprints under their belt then I would have serious concerns about their ability to adapt to change and their sincerity towards that change. What I mean is that they just don’t understand their work or its nature; This is what I mean by immaturity, and not that something else is a sign of maturity!

Indeed as the Scrum Team using Story Points really has no consistent reference they are just shooting in the dark the same as they were before.

While they have gained an understanding of the goals, they still don’t have an understanding of the predictability and thus no confidence in their predictions. We need concrete data to build trust with stakeholders that we know what we are talking about.

We need confidence!


Velocity was a way to assert that confidence with a plot of our delivered story points, and along with some clever calculations we asserted that we were likely to deliver about 20 story points. This was such a wholly improbable assumption that the vast majority of Scrum Teams talk about “carry-over” points and quiz me about how to represent that. Do you re-estimate and stick it on the backlog, does it move to the next sprint?

Scrum Teams have been basing their confidence to stakeholders on an agreed consensus that cant be compared and is susceptible to any change from the makeup of the team from the estimation room.

We need confidence!

Confidence Through Transparency

Confidence is gained by truly understanding the uncertainty of delivery and factoring it into our projections. How sure are you that you will be able to deliver? No really! what is your statistical level of confidence?

Confidence in the dace of uncertainty

In the empirical world where more is unknown than known, we don’t plan all of the work (it will change) and we cant tell you when things will be done.

Except when we can!

  • The Increment is the Confidence of Transparency of the Future – If we have a Scrum Team then I should be confident in saying that we will have a usable increment at the end of every Sprint. If that is true, then we can have 100% confidence that we can deliver the output from the last Sprint. It works, and it’s done!
  • The Product Backlog is the Confidence of Transparency of the Future – Since we have a backlog that has been ordered by the Product Owner, who is accountable for maximizing the value delivered I can be confident that what we have Done represents the most valuable things that we could have done.

With both of these being true we can have 100% confidence that we have the most valuable items that the business needs to be completed and ready to deploy. Every additional Sprint just adds to the quantity of value.

Cycle Time Scatter Plot lets you find your confidence

Using a cycle time scatter plot we can assess and find our confidence levels, and even create a Service Level Expectation, that allows us to measure progress against.

You can use this range of confidence levels to determine your current levels of predictability, and monitor the effect of changes that you make to your system on it. If you have an 85% confidence level of 16 days and you’re on 2-week Sprints then you have a problem.

This data is not hard to collect and find a full list of awesome metrics in the Kanban Guide for Scrum Teams from

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Professional Scrum Product Owner online 8th May 2023
8-11 May, 2023
12:00-16:00 EDT
4 half-days
Live Virtual Applying Professional Scrum in Minecraft on 15th May 2023
15-18 May, 2023
09:30-13:30 BST
4 half-days
Live Virtual Advanced Professional Scrum Master Online on 15th May 2023
15-18 May, 2023
12:00-16:00 BST
4 half-days
Live Virtual Advanced Professional Scrum Product Owner Online on 22nd May 2022
22-25 May, 2023
09:00-13:00 BST
4 half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

Professional Kanban


Scrum with Kanban


Teaches Scrum practitioners how to apply Kanban practices to their work without changing Scrum, bringing greater transparency and flow.

Read more

Martin Hinshelwood (He/Him) Why do you think the PSU course has become so popular for product development? Because there is a gap. A massive gap. In the product development world, we talk a lot about scrum. Scrum is not the only agile framework out there, but it is by far the most …
Martin Hinshelwood (He/Him) How important is DevOps in continuous delivery of value to customers? DevOps is imperative. It is exactly the same thing as agile, but from a different perspective. Agile The agile element of how we work together to achieve a shared purpose, common goal, and specific strategic objectives has a …
Martin Hinshelwood (He/Him) What is a common mistake made by rookie agile consultants? I think the most common mistake made by a rookie agile consultant is the belief that simply by following the rules or processes of whatever agile framework they recommend; positive results and outcomes will be achieved. A belief that …
Martin Hinshelwood (He/Him) What would you advise a scrum team to do in their first 4 weeks? That’s an interesting question because it depends on the intention of the team. In my opinion, if their intention is to try scrum, then that is what they should focus on in the first 4 …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.