YDS: How Do Flow Metrics in Sprint Planning Work?

Join this channel to get access to the perks and exclusive videos:

What Is Your Take on tracking individual story points? Let us know in the comments!

Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

For more information about Agile for Humans, visit:

#facilitation #facilitationskills #ScrumMaster #ScrumMasterTraining #Scrum #ScrumFramework #HowToBecomeAScrumMaster #ScrumMasterCertification #AgileForHumans #FreeScrumMasterCourse #FreeScrumTraining

[Bobs]

Would be great to see a video on how the Monte Carlo simulation is used in planning.

[srobot]

Love the series! The hater comments on this stuff crack me up. I’ve found in practice across 20+ different agile teams of wildly different contexts that MCs are creepily accurate, and also drastically cut down on meeting time.

It also has the benefit that you can re-run it halfway through a sprint using additional data to get an accurate revised picture of where the team will land.

It’s really important to call out the need to correctly model your forecasts and select the correct past date range of throughput to try to predict your future. I’ve seen that trip folks up.

[scrumsimplified]

How would you ensure that the number of items you are taking into a sprint, based on throughput, is of the same ‘size’ if you will. With story points for example, you may be taking stories of say different sizes to form a total number of sp. How would you translate that to using throughput?

[daniellemcclelland]

How do you calculate the risk calculations that was mentioned, ie 95% vs 75% risk?

[tomaszniemiec]

Still not convinced. All pros for using only flow metrics, can be as valid as using story points. And the cons of them could as well appear when using flow metrics wrong - heard about individual cycle times/throughput for jira issues? I have :)

[RexPersicus]

Since when Mote Carlo simulation has anything to Flow Metrics? and how disconnected from reality is this idea? In a perfect world where teams do a grand job of sizing all of their stories and tasks and properly map their realistic Sprint capacity to the committed work volume, you already are all set for a perfect predictability score. In reality this never happens and a mix of sized and un-sized stories go into the Sprint backlog and you will get mid-Sprint high priority items that need to be done and may teams keep pushing the growing Sprint backlog towards the end and would spill over at the end.

[OskarPiano]

This conversation is way too shallow, especially when dealing with engineers.
Engineers are not going to believe a single word until it all adds up mathematically at least to some minimum degree in the first place.

I know flow metrics work when actionableagile plugin calculates them.
But I can't figure the EXACT MATH behind it.
I thought this video would lay that out.

I absolutely understand CT's MATH for a single Work Item, I get how to calculate WIP in time point, I get how to calculate Throuput for a period of time.

But I can't see how average CT for a period of time is calculated (period lenght / number of work items? or sum of CTs of work items / amount of work items?).
I can't see how exactly mathematically WIP (average WIP?) is calculated for a period of time?
And I don't know how to exactly mathematically tie CT(s) WIP(s) and Throughput for a period of time on multiple work items.

When I try to fit this into Little's Law I clearly don't know how to calculate the input values.
I can't properly measure a single real example in a manner for the numbers to add up.

Theoretically for a period of time:
some way calculated WIP(s) of multiple work items SHOULD BE EQUAL TO Throughput TIMES some way calculated average CT of muiltiple work items.
But how exactly?