YDS: Planned vs Actual is a TERRIBLE Metric for Scrum Teams!

Today's we explore "Planned vs Actual" and discuss why it's such a terrible metric for Scrum Teams. Todd and Ryan focus on the anti-patterns and horrible practices that emerge when this metric is used to measure the success of a team. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.

Does your Scrum Team use "Planned vs Actual" as an improvement metric? Let us know in the comments!

This is one of those Scrum Master interview questions about Scrum that can throw you off. Do you understand why "Planned vs Actual" is a TERRIBLE metric? These Scrum Master day in the life questions can be tricky. Perhaps some Scrum Master training could help? Want to learn more about Scrum?

Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -

Join Ryan and Todd in a Professional Scrum Master course:

And make sure you subscribe to the channel!

DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!

FTC DISCLAIMER: This video is not sponsored by anyone.

Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.

#scrum #agile #professional scrum

[RieksVisser]

Great topic! What I've also seen happen is not a shoddy delivery of 100%, but a total breakdown of courage. Meaning: refinement and planning become events where every possible uncertainty is sliced away. Half the stories become a spike, reasearch or a prototype. Everything is derisked to the level where only the simple and lightly complicated is addressed. A form of complexity debt is built up as the real uncertainties are not addressed. Actual progress on product goals drop to a snails pace. But yeah, perfect burndowns, predictability and velocity. Predictably going nowhere.

[supergirls]

Love the episode. Especially you used the real example.

Question: what if those 2 PBIs (Apple Pay and Amazon Pay) are 2 of 3 parts of the Sprint Goal, such as "Enable a customer to submit 3 digital payment on our website". In this situation, should the Sprint Goal be changed to '' Enable a customer to submit 1 digital payment on our website" as well when these two PBIs can't be achieved?

Thanks!

[g-ronnmendoza]

Planned vs Actual is also the same of having a metric on sprint backlog completion rate. Such a waterfall mindset thing.

[CS-mqgd]

Another courageous conversation. Love it!

[PeterKretzman]

I feel that the thrust here was at best overstated. And that it is based on the fairly poisonous assumption that a “metric” is of necessity a punitively oriented “grade”, as opposed to a discussion opener and retrospective enabler. Any healthy team will of course consider and discuss what had been intended to accomplish and what actually did get accomplished. That’s the whole basis of continuos improvement. It’s not just a binary impression, subject to the most eloquent or powerful table thumper at the retro, that declares that the sprint goal has been accomplished so all was ideal.

[dav]

What would you guys suggest/recommend measuring to help inform decisions throughout a Sprint or even for planning ? Thanks

[tetyanamyshko]

Great session! Team can’t predict complexity. Also quality should not decrease over a course of Sprint

[claudiajap]

Great great as always. I love you guys

[joea]

Gentlemen, love the series, keep up the good work. I struggle in my current company with metrics. The company is a couple years into moving into scrum and really want some metrics. I have struggled finding any metrics to report that shows the performance of a scrum team. I keep a confluence page, that nobody looks at of course, of our sprint goals for each sprint, if it was met, what some other points of value that were delivered in the sprint and a recording of the Sprint Review. However, this doesn't create a pretty bar graph. So what are some metrics we can use for the higher-ups to show that a scrum team is being successful?

[mikeengstrom]

What should the team take away from this to help plan their next sprint? If this same things happens across multiple sprints, is it still ok? In this example, it helped that the team had a good sprint goal and pivoted early. Without those things, this would likely have had a different outcome.

[jasonpursey]

I agree with the overall sentiment that the Sprint Goal is the focus, and collaboration will result in better outcomes.

That said, there's a big missed opportunity here around helping the team measure their performance relative to their expectations. Say/Do can be used over time to help the team understand how well they understand the complexity of both the domain, their technology and each other. Without consideration of this, how reliable can their forecasts for future deliveries be?

[YouTwtFace]

IMO, this will always devolve into a % no matter what. This will go from % planned vs actual to what % of your goal did you hit. We completed "80% of our goal" aka 4/5 features done. If we give a binary "yes" or "no" that's fine to start discussion, but if I told mgmt we "did not complete the goal" they would say, well what did you do. I would say "well, we did get 80% of it done though".

[churchmouse]

I'm currently working in a SAFe environment where the team commits to features at the beginning of the PI, then at the very end of the 10 weeks, all eyes are on what was completed. It's called the Program Predictability Measure (PPM). So this idea of Planned vs. Actual is baked into the SAFe framework.

[ankhayratv]

Where can one obtain a "audio version" of this "podcast" ?

[opmdevil]

But but but...hre in SAFe, we measure not only the sprints planned versus actual but also at the increment level...that can't be right...

[robertfeldbruegge]

How do I show leadership our team’s capacity? I’ve explained that velocity is changing as we add or lose team members. So we can’t compare to a few sprints ago because the team is different. So now a leader twice removed suggested we calculate a correlation with the number of developers, their primary skills, and experience levels. E.g. a team of five “leads” should have greater capacity than five “juniors”. Funny thing is he was one of the sponsors for us to use Scrum. I have some coaching to do, but want to come with an alternative to give him what he wants, which I believe is confidence to forecast when a feature or epic will be done. I saw your other comment to use Cycle Time, Throughput, Item Aging, and WIP Limits to find areas of improvement related to planning and capacity. Do I need to quickly read “When Will It Be Done?” or can you share some tips to get me started?