Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Velocity is an average amount of estimated sizes of PBIs completed by Development Team in a Sprint. It's not an average amount of real PBI's sizes completed by Development Team in a Sprint.
I don't suppose that real PBI's size is proportional to estimated PBI's size, instead the difference between the real size and the estimated size is pretty random (every time, every User Story, not to mention estimating big features).
Looks like the concept of velocity has a flaw... Doesn't it?
Velocity measures how much work the team can complete per sprint, given a stable team and a common understanding of the complexity of the items that they work on.
It's usually measured in number of story points, or sometimes, if PBIs can be split into similar sizes, you can even count number of PBIs completed per sprint and use that as your velocity.
Velocity is not an average. Velocity is a sum of all the story points for all the PBIs completed during a sprint (or a count if you are counting PBIs). Averaging velocities comes later, when you want to make use of velocity to forecast how much work you could finish at some later time (see yesterday's weather).
Velocity isn't flawed. It's just some measurement. What you do with velocity is subject to flaws.
EDIT: based on your comment:
but the team doesn't know the complexity - the team estimates the complexity. That is the point of my question.
The velocity is a way to attach some "reality" sense to estimates.
If you would know the complexity of each item and how much it really takes to build then software development will be easy and we wouldn't need to estimate. We also wouldn't need to use things like velocity.
But because we don't know how much building new software takes, we need to estimate. And the estimates are just that, estimates. Statistically speaking, half of the time the real work takes less than the estimate, and half of the time it takes more than the estimate because you rarely land precisely on the estimate.
When teams estimate in story points, they have a discussion to understand what they need to build. The smaller the items you work on the easier to have this discussion and cover almost all corners. Then, based on that understanding, they can place that work into different sized buckets. This is a 2 SP, this is a 5 SP, etc. I want to make this clear: the point is the exploration and the understanding of the work. The story point estimate is just a byproduct of the discussion.
But you can use the story points to then see how the effort will match with actual progress of time by laying the work over a sprint. The velocity will tell you how the estimate matches with reality over a consumed period of time. If you split, discuss, understand, and estimate all other work like you did so far, then you can have a better confidence into deriving a duration for the estimate because you have some real data measured.
Obviously, you can't spend a lot of time to discuss everything into its complete details so that you get a perfect SP estimate in the end. That is extremely time consuming, causes waste, and is never a guarantee. So people discuss and estimate up to a level where they feel confident they can finish that work into a sprint. Some estimate will be lower, some higher, but overall, if you keep the same approach in place, it tends to settle into a good average because of the law of large numbers.
You can't know the "real" effort and complexity in the beginning (you only know these once the work is done). But if you are consistent in your planning and estimation, then the velocity you measure each sprint should give you a good level of confidence on how your future estimates will map out on a calendar.
The only place you need to pay attention too is that you have consistency into the things that affect the velocity. For example, if the team composition changes often, then your velocity will be impacted. If people don't know the work or understand the PBIs, then their estimates will fluctuate a lot. If you constantly change the meaning of what 2 SP means or 5 SP means then again, your velocity will fluctuate. When things like these happen then you can't count on velocity to have a good level of confidence in forecasting future work because the velocity will measure different things each time and it will no longer show a trend that can be projected into the future. So, if your velocity is all over the place, or work doesn't get contained in a sprint as initially planned, then you need to ask yourself why that is and fix that first.
You are quite right that estimates are hard to get right and that the real amount of work will include an error component.
However, there are a couple of factors that work to reduce the impact of these errors:
There is a legitimate argument that a team could calculate velocity based on the 'real' size of backlog items. However this would require extra work at the end of each sprint to work out the real size (e.g. we estimated this item at 3 points, but the actual work indicates it was a 5 point item).
The question you have to ask yourself is will the benefit from this justify the cost of the extra work?
As long as the team is estimating in a consistent way, has relatively small backlog items and not too many unknowns then the benefit of measuring actual size of backlog items is small and likely would not justify the extra time.
The purpose of velocity, and story points, is to aid the development team in answering one question:
Scrum, in particular, is meant to be a framework for developing a product in a complex environment, meaning one where the work required is not easily predictable. If the developers are doing something equivalent to assembly line construction, then Scrum isn't necessarily the right framework. But that means that both story point estimates and velocity are uncertain values that will hopefully line up on average.
Most importantly, a Scrum team should get better at understanding its velocity and the complexity of PBIs over time, so that the developers are able to deliver Product Increments that represent their best attempt at a maintainable pace of work.
If a Scrum Team consistently under- or over-estimates its velocity, meaning that either they always complete the Sprint Backlog ahead of time or fail to complete it, then that can be discussed at the Retrospective. Some drivers to investigate could be:
Does the team assume everything is significantly more or less complex than it turns out to be?
Are there impediments the team is anticipating, and is there anything that could be done to prevent them from having an impact on the team's velocity?
Does the team need more confidence in its ability to deliver work? Are they worried about consequences of failing to deliver everything that makes them avoid taking on too much?
Are some of the PBIs being brought into the Sprint poorly defined, which makes it harder to estimate their complexity? (The INVEST mnemonic is helpful here, as are research spikes when PBIs need to be better understood before they can be worked on.)
Difficulties in aligning the expected work with the work actually done could also indicate an issue in the team's Definition of Done and Definition of Ready, or it could relate to the team's culture or technical skills. It could even be a response to other factors - for example, if the Product Owner is pressuring the Developers to agree to a Sprint Goal they can't actually achieve, or if there is a growing technical debt that means simple tasks become fraught with errors.
There is an alternative method to track velocity that is especially useful for new teams or teams still trying to master the estimation exercise.
And that is to simply count how many stories that team can complete in a standard iteration.
Not points but whole stories.
In theory the story size should be taken into account when measuring velocity but in practice when you had several iterations and stories behind you, the sizes of the stories are quite evenly distributed and you can just use the number of features or stories.
It's like a road trip. You can measure the distance you travel each hour and use that data to estimate where you'll be in the next hour.
In the road trip metaphor, different cars can have different measures (km/h. mph, m/s).
So velocity must not be used for comparing different teams.
But it can (and should) be used to plan and estimate your future sprints.
I would also add to the foregoing excellent discussions that the quality of "velocity" as a metric very much relies on the quality of your "story definition process" – call it what you will.
When a developer undertakes the process of writing source-code that will correspond to it, it is very important that the "story" he is working from requires him to do a minimum amount of "discovery" (ideally: none), and "making his own decisions." Proper research needs to be done ahead of time.
"Writing software source-code" is actually a very predictable process if(!) the person doing it knows exactly what to do.
In one fairly-large project that I worked on, we found a way to add a "ratings feature" to the screen that a developer used when he closed a ticket: "What was the quality of this ticket?" And a comment section: "What should we have done to make it easier for you?" The candid feedback was extremely useful, and it was immediately acted upon.
