The Velocity Chart records how many story points are completed in each iteration sprint.
This is an important chart to have, and I recommend it to all my clients.
As the team creates user stories, they are added to the backlog. At some point, those stories need to move into the current sprint.
But how many stories should we move into the sprint? We won’t know until we’ve done some basic estimations to get an idea of how many we should pull from the top of the backlog.
If we gather too many, we risk having the team prematurely invest time discussing and detailing stories that we might not get around to working on during this sprint. Additionally, when we bring a story into the sprint, it gets locked in place, so the product owners, can’t easily re-prioritize it to be done later, or make big changes to it easily.
On the other hand, if we don’t collect enough stories, the team might start to run out of work during the sprint, and they’ll need to go back to the product owners to figure out which stories are ready to be pulled into the sprint.
So, there’s a balance we’d like to get right. We figure this out by estimating stories and having an approximate idea of how many story points we believe we can complete in the current sprint.
Discussions points for your team:
- Which is more true for your team? Velocity is used to:
- Measure team performance.
- Approximate which stories to pull into the sprint.
- Which is more true? In cases where we finish all the stories before the sprint ends, we:
- Feel we need to do a better job at estimating next time.
- Feel neutral about it and keep working with the product owner to pull in more stories from the backlog.