sorry! technical difficulties

3

The competition is a killer

Thanks again @dave great conversation and nice to meet you!

Likewise. I'm rooting for Edward Jones (and you)!

Is it possible to work agile without pointing stories?

Sure. The point of pointing is to capture planning metrics. You can do the same with similarly sized work.

On my current product we haven’t used story points at all. We aren’t that worried about planning metrics, just on what’s blocking is and what’s the next highest priority. More Kanban than Scrum.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

3 story sizes • NFI: No Freakin' Idea • 1 • TFB: Too Freakin' Big

Story counting. Regression to the mean (law of averages, so long as roughly a 1) It's the conversation that matters.

And don't forget to look where the work isn't.

This is termoundously insightful, thank you all.

I have gathered data from hundreds of teams, and I have found that work items don't even need to be similarly sized in order to provide good forecasts, as much of the total duration of any item will be spent in wait states ie low flow efficiency.

Also, Ron Jeffries has said this many times, "I may have invented story points, and if I did, I'm sorry."

@catswetel "much of the total duration of any item will be spent in wait states", excellent insight that I hadn't reached yet. Thanks.

I believe page 150 in Making Work Visible is an overview of flow efficiency. I like how @dominica has made this idea accessible to knowledge workers. We borrow a lot of terms from manufacturing, but it seemed like "process cycle efficiency" was not catching on. lol Thank goodness for "flow efficiency."

Yep, love her work.

@catswetel: struck by that same insight that Bryan mentioned. I’ve not read MWV so this may be a dumb question: if you improve your flow efficiency so that items aren’t spent in wait states does that mean your forecasts then become “worse” in that the variation in work items starts to dominate?

I highly recommend MWV. I may need to re-read it.

I don’t remember anything about that specifically in MWV and I can’t see anything on a quick flick through it again (definitely worth a reread!) May be worth seeing if @dominica is still around here. My 2c: once you’ve improved flow efficiency to that degree then slicing becomes even more important - as Jon says above, slice everything that’s TFB down to 1 point / ideal day / gummi bear and work more on things that are NFI. But then what does “forecast” mean because you’re not slicing everything in your backlog, just the top priority features. That then means you have strong confidence in your forecast for the next few iterations because you’ve sliced well. Further out - not so much, but then those aren’t your top priority features so maybe accurate forecasts aren’t so important. There’s a whole other book to be written on this (Planning Extreme Programming is a lost classic which gives it a good go).

how do we pair w/ mgmt wanting to know when features will be delivered (which PI) and what dependencies we need on other teams as part of this ritual

yeah, I have not seen accuracy of forecasts decrease in any significant way as flow efficiency increases, but the models for forecasting definitely change (from emphasis on wait times/queues to emphasis on expertise). the changes I see as a result of emphasis on decreased wait times often have the effect of driving out variability through the maturation of interfaces and platforms OR the colocation (literally or figuratively) of experts. that being said, I have seen extremely few value streams achieve anything that I would call flow efficiency rather than inefficiency. lol I am not sure that's bad, given the complexity of the systems we have created. I think it's natural (for now). It's just interesting.... 🤷 I dunno, @jtf

@syedhussainchi I always look to Troy Magennis for help on planning around dependencies. 💕 I think the most important insight I've had is to decouple prioritization and sequencing. That made my life much easier.

Also, Troy always sends people this diagram (used for triage in hospital emergency rooms). I find it very helpful:

i'll google Troy Magennis

He is one of the most magical humans currently on planet Earth.

:unicorn_face:

would you happen to have the source of that diagram handy?

kindly

It's the "ESI" Emergency Severity Index. https://en.wikipedia.org/wiki/Emergency_Severity_Index

@rohrersm See pg 94 of MWV where I touch on the perception that allocating workload by WIP limits won't fly b/c work items aren't all the same size. But size doesn't really matter b/c we can only really work on so many things at a time. It doesn't matter how big or small something is when you can only truly focus on one complicated thing at a time. When that work is done (regardless of size), you move on to the next thing. @jtf @catswetel

^this came up on a panel I was on about mob programming...reducing WIP decreases variability of forecasts

Invite<inflict 💥

Start with what happened at your last feature

I like that!

is it easier to kill a project or a product?

Yes.

Both.

Hard to kill products with high value. I believe it's the product itself that is valuable - not the project.

Remote work volunteering sounds awesome!

Love the common glossary idea

We've done this for test patterns. We are in progress on metrics.