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.

How to make planning poker work for distributed agile teams

Hey guys! So a lot of you must have used planning poker for story sizing during your spring planning or scheduling sessions. It is a very powerful tool to predict how much work a team can get done in a sprint or in the coming few weeks. More importantly though, planning poker is great for the entire team to understand the features and tasks that they will be working on in the coming sprints.

Planning poker works great for teams that are co located, but for teams that are distributed, and don't work from the same office, it might be a tricky exercise to run. Luckily, we have tools that allow teams to run online planning poker meetings as well! In this video I walk you guys through one such exercise. Hope this helps!


Kickstart Agile Series

Hey everyone! Welcome to the first video on  YouTube channel.

 I have worked with distributed agile teams for the past 11 years and helped many teams and organisations make their agile transformations. Over the course of my career, I have seen most teams face similar challenges and have he same questions, and so I thought I would help by posting these videos on YouTube. 
This is a first in a series called kickstart agile, where I will talk about how to make sure you set up your agile team and project up for success. 
To know more about agile and scrum methodologies and agile software development, start here:
To know what user stories are and how they are used in the agile dev cycle, and how to write narratives, I always go back to this:
If you have any questions, suggestions or feedback, do write to me here: 
I would love to speak with you and discuss more in the comments section below. 

Kickstart Agile

Hello world! 

Welcome to the Digital Agile Association. My name is Pritika Gulliani and I am the founder of the Distributed Agile Association.

With the popularity of agile ever increasing, scrum and agile is no longer adopted just by small co located team. As distributed teams become more prevalent, there is a need to re imagine agile teams. 

My goal here on the Distribute Agile Association is to : 

  • Create a community of people all sharing their experiences about working in distributed scrum teams. 
  • Provide tips, tricks and resources that could help distributed teams work seamlessly. 
  • Talk about the latest developments in the agile and scrum world. 

I am so glad you are here and I welcome you to join our growing community. Lets get started!