Determining velocity when everything is changing

Ragesh,

Velocity is not part of Scrum, but is a useful complementary practice to Scrum. Having said that, velocity is a planning tool to help predict release dates and other planning. In your situation, it is quite logical that your velocity would be highly variable, as this simply reflects the transparency of the truth that your team is "storming" or going through a lot of change. Velocity is value neutral, so there is no "one thing" it should generally or always be doing.

Ragesh,

Something that helped me become peaceful with the consistent change, constant up-and-downs on a scrum team was a quote from Lyssa Adkins "The joyful and willful pursuit of high performance".
Things are always going to change, people are going to get promoted, leave the company, go on vacation, be sick, move departments - if you can truly appreciate the pursuit of high performance, life everyday at work will be that much better. Share this with your team as well. The more they know, the more self-organizing they can be.

But if velocity is highly variable, doesn't that make it difficult to plan releases and know whether Scrum is even working?

> But if velocity is highly variable, doesn't that
> make it difficult to plan releases

Yes it would, assuming the Scrum Team has an estimated Product Backlog and the estimates are fit for the purpose of release planning.

> and know whether Scrum is even working?

No, because the proof of success in Scrum lies neither in velocity nor throughput or any other such measure, but rather in the actual delivery of working software by the end of each Sprint.

Note also that Scrum no longer refers to release planning and is therefore agnostic about the use of velocity. Release could equally well be performed on demand. A release plan does not need to be in effect at all.

Hi Ragesh,
Normally in order to have usable data you need a team that more or less stays the same for a few sprints. You can always try and use basic statistics to have "some" sort of idea about your capacity for your upcoming Sprint but don't expect to be extremely accurate (..). Nor should you use this as measure of your success. Working software should do the trick of you. Best of luck.

> No, because the proof of success in Scrum lies neither in velocity nor throughput or any other such measure, but rather in the actual delivery of working software by the end of each Sprint.

Surely the mere delivery of working software at the end of the sprint doesn't prove success. (Or why not just release the same build over and over?) If Scrum is impairing productivity, I would say the process isn't working. What about the 400%+ increase in velocity that Scrum is supposed to allow?

> Note also that Scrum no longer refers to release planning and is therefore agnostic about the use of velocity. Release could equally well be performed on demand. A release plan does not need to be in effect at all.

Does that mean no sprints? Or that sprints are not necessarily correlated with releases? Do we still need to plan what goes into a sprint, even if we don't plan what goes into a release?

Hi Ragesh,

I think Tim is right

As we're living in a complex environment, we have to handle many unpredictable changes (e.g. in scope, staffing, processes, contracts, ...). Even with the most detailled and foreseeing planning, we won't be able to predict all changes. Therefore, we can't help but adapting to changes (inducing decreased velocity at times) - or failing. This is true for Scrum Teams as well as for Teams in Waterfall. So all (Scrum and Not-Scrum) predictions are vague. The difference is: Scrum and other agile approaches acknowledges these unpredictable changes and demands short-time Sprints so that the current state is frequently inspected and made transparent. And then you can adapt. With waterfall-like processes, you just can't see (and thus can't adapt to) the uncertainty, but it's still there.

Jurgen Apello wrote a really entertaining and though educating book about this issue: "Management 3.0: Leading Agile Developers, Developing Agile Leaders".

Of course, if you "only" want to solve a release planing problem, this won't help you very much. But the topic fascinated me - and if it's the same for you, the book might help you to accept and embrace change.

Best regards,
Anke.

Oh, and to your last questions: Scrum does definitely require Sprints and Sprint planning. But Scrum does not tell you, how much work to do in each Sprint. And Scrum does not prescribe how much to plan in advance - it just recommends gradual Backlog Refinement (=Backlog Grooming), just as needed in the specific context. On the other hand, every Sprint should produce a "potentially shippable Increment" and it's (solely) up to the Product Owner if the Increment goes into release or not.

> Surely the mere delivery of working software
> at the end of the sprint doesn't prove success.

Correct, it doesn't. It is better to say that the proof of success can be found in the incremental delivery of working software and in its subsequent inspection.

> What about the 400%+ increase in velocity
> that Scrum is supposed to allow? 

You won't find that in the Scrum Guide. It's the actual delivery of working product which is considered to be important.

> Does that mean no sprints? Or that sprints
> are not necessarily correlated with releases?

Sprints are essential to Scrum, but are not necessarily correlated to releases on a 1-to-1 basis. Each end-of-sprint increment need only be *potentially* releasable.

> Do we still need to plan what goes into a
> sprint, even if we don't plan what goes into a release?

Yes, that's correct. Sprint Planning is one of the 5 mandatory Scrum Events. Release planning is not.