velocity use
hello everyone,
I have some doubts about velocity use. where is it used and by whom?
sprint planning meeting section describes "select how much can be completed within a sprint may be chalenging. However, the more the developers know about their past perfomance, their upcoming capacity and their definition of done the more confident they will be in their sprint forecasts.
hence, is the velocity a mean to calculate the past perfomance ? it looks to me it is calculated by Developers to monitor their progress during the Sprint, hence, is it used to understand how many items select during the sprint planning, so the velocity of past sprints is an input of sprint planning along with Definition of Done, upcoming capacity. I also believe they use other analysis from burn-downs; burn-up or cumulative flows to pick the right number of product backlog items in the sprint planning
about PO, does they also calculate it to analyse the progress to the Product goal during the different Sprints?
any other examples of using the velocity?
does the scrum master use too?
Thanks
Flavia
Velocity can be used to project all of the things you mention, bearing in mind that the principal measure of progress is value delivered. Velocity is quite simply what it is observed to be...the rate at which Done work is completed. It does not represent value nor is it a control surface for improving a team's productivity.
hi ian,
thanks for the input, so how do the developers know their past perfomance?is that based on the delivered value and only then on velocity, charts analyis etc..?when they pick the items in the sprint planning, what drives them?
my doubt is how they know their past perfomance so that they can pick a valuable number of items
Thank you
There are lots of ways for the Developers to understand their past performance. Velocity, often expressed as the completed number of story points, is one tool that can be used. The Kanban metrics of throughput and cycle time are a common alternative, tracking the number of items completed per unit of time and how long it takes to move work through the process. I've worked with a team that was really good at just a "gut feel" based on available working hours (removing holidays, planned time off, etc.) and didn't use any formal metrics.
The primary focus should be that the team should bring a reasonable amount into the Sprint. They shouldn't regularly be scrambling to make sure that work is refined and pulled in after planning. They shouldn't also regularly pull in too much work. How they do this is entirely up to the team and there are lots of ways to use counting, size estimation, and effort estimation to work out how much work the team has done in the past and comparing a similar upcoming Sprint to a recent past Sprint.
thank you!
I didn't see any specifics of tools to measure past perfomance and pick the reasonable number of Product backlog items in the sprint planning, did you see any questions for kanban metrics in the PSM I, if you remember?
from scrum guide I have understood developers can choose the method they prefer most
Flavia
It's been a long time since I've taken the PSM I, but I don't believe that specific metrics, Kanban or otherwise, would be covered on it. From what I remember, the vast majority of the questions focus on the meaning and intent of the Scrum Guide.
As far as your understanding of the Scrum Guide, I'd say that it's close. I don't think that the Developers can choose any method they prefer. According to the Scrum Guide, the Developers are accountable for creating the plan for a Sprint, and in an ideal world, they'd be able to choose their preferred method. In practice, though, the ability to easily gather and review data plays a role so there could be techniques that are easier to apply. Even though those easier techniques aren't the Developers' first choice, they may decide that it's better to use the information that's easy to gather than add overhead to gather the data they need.