What do product backlog, story points, and velocity have in common? They are all components of Scrum, an Agile framework, that allow us to estimate how much can be delivered in any given time frame. First, I will outline some basic definitions, and then I will share a real-life practical example of how these three elements work together to provide valuable project information.
The product backlog is a collection of user stories prioritized by what needs to be delivered first. Each user story provides information on a system feature needed, who it is needed by, and the feature purpose.
Each user story is assigned story points, which indicate how large or how small the story is in relation to the other stories. Story points do not relate to a specific timeframe or hours of effort required by team members. Rather story points are only relative to each other, and they are assigned using estimation techniques such as t-shirt sizing, planning poker, Fibonacci, and triangulation. The idea is to get some consistency in general size related to other user stories rather than precision in the number of hours required. Story points are assigned by the project team in a group setting.
Velocity is the speed at which the project team can complete user stories in an iteration (aka sprint). Velocity begins as an educated guess early in the project and then gets refined in a proven number as the team completes more iterations. Major changes that will affect the speed of the team, such as adding or losing team members, will result in a new velocity.
The product backlog contains the user stories and the story points assigned to each. The team experience dictates the team velocity. Once these components are in place, the team can now pick the appropriate amount of user stories off the product backlog in order to deliver a successful iteration.
The product backlog displayed below comes from an actual Scrum project I worked on. Click the image below to see full size.
In this example, we had just completed the first full release of the travel reimbursement software and were getting into planning the second release. By now we knew what our team velocity was. I was able to use this known velocity and apply it to the product backlog to show the sponsor how much work would likely be completed and when. I prepared a forecast that showed how much of the system we would likely have completed given a target date for the release.
The sponsor was able to get the information she needed from this forecast in order to make a difficult decision. We would not be able to release the functionality that was desired by the hard end date for the project. Therefore, the second release was cancelled.
The time it took to produce the forecast using story points and velocity was very quick. It was a granular and precise forecast, but it was accurate.
While this is a high level overview of how Agile processes using Scrum can aid project and release planning, it is just the tip of the iceberg. Check out our other Agile articles, Agile blog posts, and our Agile classes for more information.