Story points are not your sprint deliverable!

On multiple occasions, I have been asked this question 'how do you explain the drop in velocity for a team?'. This question has been asked by clients, product owners, delivery managers, product managers, agile coaches and many more.

Many times I have been told that a team needs to 'hit' a certain velocity, sprint after sprint. There are 2 things wrong with this way of thinking. One is that there is lot more that goes on in a team, that contributes towards their velocity. It merely isn't just the number of story points done. Second is that this way of thinking inherently believes that the deliverable of a sprint is the number of story points completed in a sprint. Let me explain these two points further.

The velocity, or number of story points per sprint sometimes seems like the only metric a lot of agile teams seem to track. To me, the velocity of a team does not give me the full picture of the team's progress. For example, if a team's velocity has increased, but the number of bugs per sprint have increased too, would that count as progress? Or if the velocity has increased, but team morale, or customer satisfaction as dipped. What does that mean? Has the team 'improved'? What about if the velocity has spiked, but the team is just working on easy to complete tasks instead of tackling actual complex high priority items? As you can see, velocity, as the only metric to track is misleading.

The other point here is that teams do not deliver story points at the end of a sprint, or a week, or a month. The deliverable is working software. Working software, that is in line with what the end customer needs. There are many things that go into defining what 'working software' is, and that is for a different post. The point I am making here is that instead of focussing on the number of points to be delivered in a sprint, product owners need to focus on the features that have been added, bugs that have been fixed, business value that has been created.

So does this mean that tracking points is not useful? It is, to some extent....for the development team. I would go so far as to say that the product owner does not even need to know about the team velocity or how many points a particular story is. Story points help teams make some long term predictions of how long would it take to get something done. For example, if your product backlog is 250 points, and your team average velocity is 10, then it would take about 25 sprints to get a product out. However, once you are sprint planning, you cannot say that the team has an average velocity of 10 points, so we will pick up 10 points worth of stories. It doesn't work that way. There are so many things that go into planning a sprint.

For my product teams, during the sprint planning meetings, the team just looks at the product backlog, pick the most business critical items(which can get done in the next 2 weeks), and works on those. There is no talk of story points, just about commitment. Committing to what the team can get done in the current sprint. Mature teams know that velocity changes from sprint to sprint, so the focus should be on getting valuable work done and setting a sustainable pace.


Hope you found this article useful. For any questions or feedback, feel free to write to me at For more content like this, check out or my Youtube channel.