24

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 ...


20

Your problem is not that you have developers and non-developers (as you call the business analysis/product owner, the designer and the testers). Your problem is that these people have individual ownership on their slice of the cake and not on the entire cake. Here are a few things from the Scrum Guide (emphasis mine): Development Teams are cross-...


19

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 ...


16

Your team appears to do mini-waterfall development within each sprint, which is a known anti-pattern, as you don't get the collaboration within the team that make agile methods successful. Also, Scrum only has 3 "job titles": Product Owner, Scrum Master and member of the Development Team. There are no separate developers and testers, they are all equally ...


10

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, ...


10

You are doing a lot of good things already, but I would also recommend the following: Reduce how much you bring into each sprint Keep on reducing it until the testing bottleneck disappears and the team completes all the work they allocate to a sprint Continually reinforce the point that the team's job is to deliver completed items, not to do lots of coding. ...


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 ...


9

Other comments here all ring true: too waterfall-y, not enough team responsibility, etc. but I'd like to emphasize a point made just once in other answers: you're absolutely setting goals too high. You HAVE to set bite-sized goals that are achievable, no matter how slow that is. If that doesn't fit the business schedule, the business schedule cannot be met ...


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....


7

Stop Abusing Velocity I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated. So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable....


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 ...


6

The first question I would want to consider in your position is: Are the issues being seen in test because the code is unreliable, or because the requirements have not been understood? The developers are presumably getting bogged down in ensuring the correctness of the code, but of the following two scenarios: The developer writes what they think should ...


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

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 ...


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

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 ...


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 ...


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

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

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

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 ...


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