We’re rewarding the question askers & reputations are being recalculated! Read more.
23

Velocity is not a valid measure of team or process improvement. Velocity, especially when it is based on Story Points, is extremely unstable. By itself, Velocity doesn't reflect the capacity of the team, but capacity will limit Velocity. It's also easily disrupted by changes to the team's way of working (which includes the definition of what a Story Point ...


17

TL;DR Should velocity increase with time? The simplistic answer is that a project's velocity should only increase until the team has developed a stable, predictable cadence that can be maintained over time. There are a few caveats, of course, but it's a solid rule of thumb. Targeting an indefinite upward trend on velocity is a "project smell" that the ...


9

TL; DR Low but steady velocity is usually fine. Steadily-declining velocity is a strong indicator of an unidentified process problem, which the Scrum team needs to identify and make clearly visible within the project. Velocity is a Range First of all, velocity is not meant to be either a management target nor a fixed value. It's an estimation tool, and is ...


8

TL; DR Velocity is not a management target. It's an estimation tool, and you should be using it as one tool among many to help plan your Sprints. Don't treat velocity metrics as targets, or maintaining a given velocity as the primary goal of each Sprint. Hours and story points have no direct relationship to one another. Story points measure relative effort, ...


8

Sorry, but that is not what the article says at all. The purpose of measuring the past is predicting the future and no one in that threads claims different. What is claimed though and I absolutely agree is that you should not predict the future in absolute, precise, single values. If I go from one city to the next by car, I will say "I'll be there in 2-3 ...


7

As pointed out by CodeGnome, velocity is always going to be a range. However, if you find that your velocity fluctuates a lot, here are some things to check and suggestions for improvement: Do you account for holidays? For example, if you run 2-week sprints, you may have one sprint with 2 holidays which is 20% less duration than a normal 10-workday sprint....


6

Story Points Are Never Time Estimates Is doing: S = 1/2 a day (maximum) M = a day (maximum) L = 2 days (maximum) a good approach? Absolutely not. Story points measure complexity and the level of effort required to complete a feature, including the team's Definition of Done. It is not, and should never be, directly mapped to units of ...


6

TL;DR In your rather long question, this mixture of issues stood out as the gist of what you're really asking about: Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still ...


5

TL;DR Calculating velocity is relatively straightforward if and only if you treat it as a rough estimate for forecasting. If your metrics imply great precision, you're using velocity wrong. Having said that, the two most common techniques are: Trailing average. Median with confidence intervals (e.g. "a range"). There are many variations on these ...


5

Usually when people talk about velocity, they actually mean average velocity, so you could just average all of those. Now, teams change and improve over time, so often times we'll use a rolling average of the last 3 - 4 sprints. Personally, I like to use the last three excluding any oddities (like sprints over Christmas). The reason I ignore these oddity ...


5

Velocity is not something that is calculated, it is measured. Velocity is the amount of work that is completed in a Sprint. In this particular case, since you estimate work in Story Points, you will have a Velocity in Story Points. At the end of a Sprint, you can look at all of the work that is Done (per the Definition of Done), sum up the Story Points and ...


5

Your concern is absolutely correct. Velocity as a team improvement metric is problematic because an improving team will often see their velocity increase but just because the velocity increases doesn't mean the team is improving. What you really want to look at is value delivered. There are a number of ways to assign value to work. If your team is already ...


4

Measuring Velocity According to one source: Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers - all of which are considered acceptable. However, most sources don't really explain that velocity is based on the idea that you can extrapolate your ...


4

We have finished a story which is no more required by PO/Management. Surely this story is not going to add any business value. What to do in this case? Should we count the effort in velocity or not? Velocity is primarily (and most effectively) a metric for estimating a team's capacity to do future work within a Sprint or series of Sprints, and is not ...


4

The calculation part of velocity is straight forward as you can just sum up the story points completed in each sprint and divide it by number of iterations. This will be 23 in your case for the data that you posted. However, the whole point of Why to "calculate" velocity is worth mention here... In Scrum, velocity is how much product backlog effort a team ...


4

TL;DR Velocity and technical debt aren't directly correlated, and velocity can't measure technical debt directly. However, velocity (when properly implemented) can act as a detective control to uncover hidden debt. Technical debt isn't necessarily bad. Just like financial leverage, there is good debt and bad debt. Taking on debt the project can afford may ...


3

It depends vastly on several different factors, perhaps most importantly on which stage the Team is in in the 'Forming, Storming, Norming, Performing' process. If the Team is in the Performing stage (that is, they're already performing at their 'optimal efficiency'), then I would expect velocity to be more or less static... when ignoring fluctuations caused ...


3

My suggestion is to look at a development life-cycle that I've seen used in some "Waterfall Release" companies using agile. The key to this is the word "Potentially" as in "potentially releasable Increment of “Done” product at the end of each Sprint.". Scrum doesn't actually say to ship every sprint. It just says it should be releasable. This has been ...


3

The zig-zag is usually caused when a majority of stories are longer than the length of the sprint, so you end up with one sprint where little is completed, and one where lots of stories are finished and velocity is high. Plot yourself a histogram of stories against how long they take to complete (actually take, not the story points), and you'll probably find ...


3

Looks like your Scrum team does not have a Product Owner nor a Scrum Master However, if you do, get your Product Owner to prioritize the stories and get your Scrum Master to receive and manage all requests for your time. Your team (and you) should focus on one highest priority story (as decided by your Product Owner) at a time and take it to 'done' status. ...


3

TL; DR The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration. When Scope Changes Mid-Sprint Scope changes really ...


3

Strictly speaking, the PO shouldn't be changing stories in the current sprint. For Scrum, best practice would be to abandon the entire sprint and start over with a new sprint planning session, new burndown etc. Other stories currently in progress can still be brought into the new sprint of course. As for timesheets - you should probably ask whoever ...


3

Draw a line that represents the rolling average over that period, then draw lines that represent upper and lower control limits at 1, 2, and 3 sigma. Then analyze again. Your Y axis goes from zero to 1,000 which can make normal variation look extreme and volatile. You must use control limits to determine if you have a special cause. Else, you have normal, ...


3

If 2x5 does not equal 10x1 then your relative sizes are off. A 5 means it 5 times more complex then 1 on average. On average it will also take 5 times more time to complete. Still velocity is defined as the number of points you achieve in a Sprint. Just sum them. Then it is wise to average velocity of the last three Sprints, something Jeff Sutherland calls ...


3

TL;DR You can express velocity in a number of ways. The two most common are the sliding average and the range. A sliding average is generally easier to calculate, and often provides "good enough" data for agile planning. On the other hand, a range can be more effective at setting stakeholder expectations. Using a Trailing Average Calculating a standard ...


3

Velocity and Capacity 20% of the team left during the particular sprint. Does the velocity change? It is likely that your velocity will change because the team's capacity has changed, but a lot depends on the work that the team has planned for the Sprint and the cross-functional composition of the team. As a rough planning value, you should probably ...


3

Hitting the nail on the head One thing I'm worried about is that team can easily game this by simply estimating higher. So instead of task taking 2, they would give it 3. Creating an illusion of improving velocity. This is a spot on recognition of the flaws of using velocity as a metric. Though also note that it's not always an intentional gaming of the ...


2

You may want to use earned value management techniques. These should give you an idea of progress to date in comparison to the baseline plan and also allow you to extrapolate future progress. As with other forms of prediction, the accuracy of the estimates will improve as you get closer to the end of your project. The main problem that I have had with EVM ...


2

Story Points measure a combination of Complexity and Effort, which is what makes them hard for people to understand. Risk, uncertainty are likely also components that are part of the estimate. In the end velocity is a measure of what you have delivered in the past (few) sprint(s). It's an indicator of what you can expect to deliver next sprint when nothing ...


2

When I am reading "near to the end of a sprint" it means that your sprints are too long. You need to shorten your sprints. That's the main thing that you need to focus on. You have the answer within your question.


Only top voted, non community-wiki answers of a minimum length are eligible