Let’s say that you decide that you want to start marking things off of your bucket list. For those who don’t know, a “bucket list” is a list of things you want to do before you….ahem, kick the bucket.
If running a marathon is on your bucket list, you may want to answer some questions. For example, how long will it take you to run the race?
To figure this out, you need to know how fast you can run a mile…
Yeah…That’s not going to work. A marathon is 26.2 miles long. You need to estimate what your pace per mile will be over this distance. Normally, you don’t do a long run more than 20 miles during a marathon training cycle. So, how do you guesstimate your marathon pace? Do you pull that number out of the air?
No…what most folks do use is a pace calculator. You plug in your time from a recent race (say, a 5k), and it will estimate how long it will take you to finish the longer races.
This is how Velocity works in agile.
Velocity is defined as how long teams get backlog items done. In other words, it’s how quickly the scrum team can deliver value to customers. An agile team doesn’t go through the story sizing exercise for the experience….It is done so that we can determine when the project will be ready for release.
It works like this. As a team you have a backlog of stories and Epics (which are in reality really big stories or ideas that need to be broken down). During release planning, stuff gets moved into a more focused release backlog; This should reflect what is in the release charter. It’s not necessary for all of this stuff to be fully groomed – the goal should be that only two or three sprints worth of stories are fully groomed.
This may not make sense to you, but it’s a good idea. Remember, the idea here is to be fluid and react to feedback. Why spend time grooming stuff you may or may not be changing (or even doing).
The key is that everything in the release backlog is estimated. All stories and epics have point values.
This gives you a number. For simplicity's sake, let’s say your release backlog contains 500 story points.
As your team works through sprints, you will get a pretty good picture of how many story points they will be able to complete per iteration…that’s your team velocity.
So, if your team’s velocity is 50, it should take you ten sprints to complete what’s in the release backlog. Velocity will remain at least somewhat constant over the life of a project. This makes velocity useful for predicting when a project will end. If the work in the release backlog changes (for example, the product owner adds stories and increases the number of story points due to customer feedback) velocity will tell you when the team will be done. This is why velocity is defined in units of value (stories) instead of units of effort (tasks). You get an accurate picture of when the team can realistically get the work done.
Gone are the days when the development manager would set the release date. In Agile, the ability of the team to deliver value is what will make that determination.