Return to site

SCRUM: Escaping the Velocity Trap by Kurt Bittner

· scrum

Somebody>What should an Agile organization measure, and where should they start?

Kurt>Start by measuring customer outcomes.

Somebody>What about stuff like velocity?

Kurt>What’s better? A hundred story points in the wrong direction, or one story point in the right direction?

⚠️ Output matters, but only when delivered outcomes are right

Teams who measure their velocity but don’t or can’t measure customer outcomes may, quite simply, be driving in the wrong direction.

🌱 The root of the problem is that most requirements are wrong

Measuring velocity would be the right thing to do if you could be sure that you’re building the right thing.

Product Owners are not somehow magically omniscient; they could be misleading the product.

Only a third of the ideas produced positive results.

The Top Toyota waste type is overproduction: producing items for which there are no orders.

🔎 Focus on Outcomes, not Outputs

Velocity measures OUTPUTS.

It really doesn’t measure useful work.

Don't deliver many features to customers, say lots of output, that don't really improve the OUTCOMES that they experienced.

🤔 Making hypotheses explicit helps

Measure customer experiences!

State the PBI as a hypothesis, not a statement of fact!

Every PBI is really just a theory about how you are going to make a customer’s life better.

✅ “Done” really has to mean “in use”

Testes, deployed to production are not enough to be said 'Done'.

It has to be used to say it as 'Done". #veryHighStandard

⌛ Why Lead Time matters

Lead time=the time between when an idea is conceived and when you can measure the results.

If the lead time is too long (>4w), you will get lost.

Conclusion:

1️⃣ Product Owners must state PBIs in terms of outcomes and success measures.

2️⃣ Product Owners must set Sprint Goals in terms of outcomes.

3️⃣ The Development Team and Operations must work together to create a reliable delivery pipeline.

#scrum #velocity #trap #outcome