Time to stop the madness. Time to stop estimating.
Вставка
- Опубліковано 21 бер 2023
- The biggest problem in Agile today is the degree to which we rely on estimates.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
📎 Grab your FREE "Estimates vs. #NoEstimates" Cheat Sheet: pages.developmentthatpays.com...
🎬 Watch this 4-part series from the beginning: • #NoEstimates - How to ...
🎥 Watch Woody Zuill at Agile India 2017: • No Estimates? By Woody...
Image by cookie_studio on Freepik
- www.freepik.com/free-photo/cl...
-------------------
153. Time to stop the madness. Time to stop estimating.
#NoEstimates #DevelopmentThatPays
Today’s episode isn’t just the end of this series, it’s the end of a journey that began 6 years ago… In 2016 - I asked the viewers if this channel about worst bit of agile And discovered that I wasn’t the only one that had concerns around estimates. It’s a thorny issue - especially as the process of estimating - is generally well-regarded as a great way of getting shared understanding o the work. A weird case of the means justifying the end A couple of years went by and I eventually knucked down to build a course on how to get better at estimating. I had most of it done and dusted when I stumbled across THIS VIDEO. And it really spoiled my day. This is Woody Zuill. Woody, as you may know, is the originator of #NoEstimates. I’ll put a link to the full 90 minute talk in the description below. But I want to play you a very short section where he shares an analogy // is that enough “Maybe not eating the junk food is the best solution“ The moment that I saw that, … I couldn’t say how or why but.. I was sure it was true. What we’re trying to do with estimates … … what I was trying to do with my course … is the same as trying to “chew junk food better.” We shouldn’t be trying to get better… get rid. For the first time I saw that there’s a whole industry out there dedicated to “how to estimate” and “how to get better at estimating”. And I knew right then that I couldn’t have any part of it: I had no choice but to take a hatchet to my course. // I’ve worked this in later Of course, eliminating [getting rid ] estimates is easier said than done, given that they’ve somehow weaved their way into, well, just about everything we do: Take a look at this: We start by estimating. That gives us Estimates. From estimates (over multiple Sprints) we can calculate (derive ) velocity And estimates and velocity are used jointly and severally for, well, all kinds of things: And for all manner of charts and reports - Burn ups, burn downs, that sort of thing Including… Forecasting // Say why splitting out selecting items from the Sprint Backlog So yeah, we’re tied in. Sadly, there’s a lot here that isn’t… ideal Not just the [potential] evil-ness of estimates (as we talked about in Part 1) But also the impracticality of Forecasting, requiring, as we saw in Part 3… the entire backlog to be estimated.
• Time to stop the madne... - Навчання та стиль
Welcome to the NEW and IMPROVED version of this episode. (I messed up the first version; I won't bore you with the details.)
Hope you enjoy it... and remember to grab your Cheat Sheet: pages.developmentthatpays.com/cheatsheets/estimates-vs-noestimates
I listened to half this video before writing this comment. All of this scrum reporting is to provide a pacifier to management and has little to do with developing new software. It's such a waste of time but it reminded me of a story I dealt with 20 years ago. Programmer A was asked to quote an end project date. He did, and he actually met the date, delivering the software product on time. I was told to follow his process to create an estimate that would be met. What management did not realize was that Programmer A way overestimated the solution development time and spent the last 6 weeks playing online chess waiting for his delivery date. Instead of following his process, I tried to explain to management that 'estimate' is an estimate and not an actual final number.
Love it. A perfect example of the madness around estimates.
A shame, that I only discovered this video now and not earlier.
I (software developer) have had these arguments about estimations for several years across multiple companies now.
The only good argument about holding on to estimations that I ever got was the part about validating the common understanding in the team.
So if half of the team estimated three story points and the other half estimated eight, we usually found out in the following discussion that there were completely different understandings in place.
I really like that you both mention and tackle that point in your video as well.
But I also have to agree that the story slicing also isn't easy.
At least in the team of my current employment, where we're working on a shop system, the stories are already cut down in very small pieces regarding their functionality.
That doesn't help that much though, because it is built on a very complex infrastructure.
So for example a story can be to show a new label on a product on the product detail page.
Regarding the story, I don't think that you can get it small. What you can do though is to add a lot of technical tasks. In this particular project, one technical task could be to retrieve the information for that label from the CRM system. Another task could be to integrate that value into the specific mappers and transfer objects.
Another task to validate that it's properly published into the cache. Another task to add it to the API that provides the data to the frontend.
And then another task to actually show the label in the frontend.
If you think "Gosh, that sounds like a really complex system!", I'd answer "It's not complex, it's ridiculously over-engineered!", but that's another topic :D
But apart from the particular example, I think that this has more multiple advantages:
- Smaller pull requests. Reviewing a PR for three files that add some very minor extension to the system is easy, but one with dozens or even hundreds of changes is hard.
- Faster feedback. If you for example have your first PR where you just create the skeleton for a new module and you immediately get the feedback that there is already a module which you could just extend, you spend less time working into the wrong direction. Ideally, these risks would already be mitigated by working in pairs or groups, but that's another topic ^^
- Less conflicts. If you create small PRs fast and als rebase and/or merge the target branch back on a regular basis, you will have less and smaller conflicts with other changes.
- More parallelization. If you have the manpower, you can have multiple people (or even teams) tackle different parts of the same issue at the same time.
But that's just my current opinion on this topic and some of it has not yet been validated by myself, even though I'm trying to try it out myself.
By the way; The example for the label is a real one from my current project. It was one of the first actual tasks I saw in that project and the resulting PR hat more than 2500 changed lines in a total of 42 files.
For adding one label to the product.
It got marginally better, but a software like that in combination with a management that is resistant to advice made me quit and now I'll try out all those great concepts in my own projects while working as freelancer on the side :)
This channel is in every way my cup of tea, thank you!
Thank you! (Extra points for mentioning tea!) 👍
Great video Gary, Sprint Backlog and Planning a Sprint, off the cuff, I would suggest starting something like this:
Strategy (Scrum Team + stakeholders) - What is the direction, what are the alternatives, what is "done", which directions do the Developers believe possible, how confident are they. I would encourage inspecting in the Sprint Review, but could be done at first Sprint Planning.
Sprint Goal - essential for describing why the Sprint will be valuable from the above input
Story Slicing - What could achieve the Sprint Goal, how small should be a PBI?
Definition of Done - How confident are the developers that a PBI is achievable?
Inspect and adapt - Focus on delivering an increment during the Sprint, slice more and as you learn more.
Define failure, it is key to have expectations well understood right from the start.
How does this sound? What would you improve, remove or add?
We have been discussing "To estimate, or not to estimate, that is the question". These videos and discussions, and links to others, is very helpful in the discussion. Problem is, management has bought into the whole "estimating" argument, and now we have to break them of this paradigm. Thanks so much for the information! Very informative. ...and ultimately, whether a team chooses to estimate or not, at least now there is information for both sides of the argument.
Ah yes, I can see that having the management involved... "complicates" the issue :)
This is a must watch - many thanks
Nice of you to say so!
I agree slicing stories into small stories is good, especially at the top of the backlog. This would help the team & stakeholders to understand the upcoming work better and It fits with the best practice to have more detail at the top and less detail at the bottom of the backlog.
For a forecast covering a reasonable timeframe based on the average number of small stories delivered per sprint, you would have to slice up enough stories into small stories from the top down through the backlog to cover the forecast timeframe. So to forecast for 6 sprints with an average throughput of 10 small stories per sprint you would have to slice up the top of the backlog until you have 60 small stories. This would give transparency of what would be delivered when for the next 6 sprints.
However, without sizing / story points, the team would not be able to be as transparent as possible about how much work is left in the backlog below those 60 small stories... And slicing up the whole backlog into small stories or slicing up all stories from inception leads to wasteful detailing of lower priority stories that might change or not even be needed over time...
Just a thought: Perhaps the team should slice the top of the backlog into small stories (equivalent of say 1, 2 or 3 story points) for 4 sprints and give the stories below them quick preliminary story point estimates using the 3 amigos technique..? Workable detail/certainty at the top and less detail/certainty at the bottom. Potential for a reasonably certain short/medium term forecast plus transparency about a the clearly more uncertain long term. What do you think?
It's not necessary to slice the entire backlog in order to forecast - although I understand why you "went there". I'm working on a new video that I hope will clarify things.
I love the throughput idea!! Thanks
It's powerful. And easy to count/calculate.
Great video. I really like the point about using throughput as a measure encourages teams to work towards smaller stories. Any self-reinforcing mechanisms like that can be very helpful.
I'm glad you picked up on that. Powerful.
Oh boy, i liked the content and animations. really got me engaged through the whole video. I am part of an organization that is not mature enough with estimations. Until we get to something like this we are measuring the estimation in hours required to complete a unit of work. Thank you for the video!
Erik - Thank you for making my day! DELIGHTED that you liked it 👍
Awesome explanation! Love it!
Thank you!
Great stuff Gary. What's your take on Epics and stories; T-shirt sizing and dare I say it SAFe?
Great video Gary! I like the way you express the idea with animation. Very straightforward!
Instead of getting rid of estimating, can we do story-slicing to get better estimations?
I think the information of story points is not quite like junk food. It can be helpful in some use cases.
Your comment reminds me of a team I worked with recently. The first time I joined them for an estimating session, I couldn't believe what I was witnessing. But then it happened 2 weeks later. And again 2 weeks after that. Here's what I saw: item after item after item was assigned a 3 or a 5. Very occasionally, there was one that fell outside of this range. I was amazed!
What's my point? It's this: when you get to a point where (almost) every Story is a 3 or a 5 *there's no longer a reason to estimate!*
Back to your question: "Instead of getting rid of estimating, can we do story-slicing to get better estimations?" Yes, that will definitely help. And you might find it helps so much, that the estimate it no longer required!
Hope that makes some sense :)
We have come full cicle; "small stories" is the same as atomic requirements. So much for agile vs "waterfall".
(Small) Stories are indeed atomic. Does that really bring us back to waterfall? (Did I misunderstand?)
I really like the animations and sounds. The content too, of course ;-)
Thanks, Daya!
How do you know if a story is small enough? The whole point of planning poker is to gather consensus about the complexity of a story and decide if it's small enough. So, I ask again: How do you decide if a story is small enough?
It's not really about deciding if the Story is small enough - that's Planning Poker thinking: "We've got this thing... it looks pretty complex... let's take chunks out until it feels manageable".
Story Slicing comes at it from a different angle: "We've got this thing, and it looks like it could be broken down this way, or that way... or this way AND that way." And then we cherry-pick: *including* high-value stories... and *excluding* anything that looks (at this moment) complex.
@@Developmentthatpays I want to understand the difference you're suggesting. Are you saying as long as it's "manageable" then that's small enough? You're video suggests that "going small is everything" and I want to understand how we all agree that it's small enough to be manageable. How do we know when it's manageable? What is the definition of "manageable" for the team?
Edit: I went back again to read your response and I'm still a bit stuck. How do we know when a story is broken down enough?
I think I'm saying "if you can, you must!" And that might sound onerous, but it really isn't. It actually becomes a fun game to spot those "hidden" sub-stories. (And it's a lot easier when you know that patterns/heuristics.)
--
I remember a 1-to-1 I had with a team leader: he was was (essentially) mocking a colleague who had the habit of taking an assigned ticket... and splitting into 2 (or 3, or more). My team leader clearly thought that this was a HUGE waste of time; I disagreed!
@@Developmentthatpays Thank you for explaining. I'm curious, what does your definition of "done" typically look like under this guidance?
@@GregMontoya1 - As (I hope) I said in the video, the result must be potentially shippable.
Do not agree on the point that story slicing is easy.
2 reasons:
1. You are assuming that it is already known what the slices might be.
Idea of estimates are that you can estimate anything, but you can not always slice everything.
Often tickets created on green fields projects can be abstract or contain an element of the unknown.
It becomes a problem for short term forecasting. I have this important next epic, by when will it be done?
2. The admin it takes for teams to slice stories are arguably just as long as it may take to estimate them.
- "So lets slice this story, lets start identifying what needs to happen. How many components will be touched? Is it something we have done before?"
- "Well.. not sure.. first we need to see if we find out.. then we need to do this.. but I would have to come back to you on this.. not sure"
Get my point? More tickets and discussions with slicing just moves the effort for the team to understand a story before taking it on from something called "estimates" to "slicing".
Is the one then better than the other or not?
I'm willing to give #NoEstimates a try and simply blindly pull in a number of stories without slicing.
Over time with enough data anything becomes defensible, until the stakeholder asks: "This epic, by when?" then.. again its ooh aahh..
At least in that case a reasonable answer from scrum is possible where a much wider range is possible via #NoEstimates.
What is we simply say, rough estimates is good enough, no slicing required.
Small, Medium, Large. We map story points onto it and call it a day.
At least I will not have the Product Owner prioritizing the backlog, ask the question ANYWAY, since he would like to know when a particular coming item will be done to coordinate with other teams..
Sorry, but this is one thing that I cannot get onboard with. In order to load a sprint, you have to have an idea of size, or things get pushed. In order to keep people from padding (adding extra stories to increase throughput) you have to estimate somehow. There are so many red flags to this approach. In a perfect world, YES it will work, but this is not representative of the modern workforce and how they work...
It’s been 5 months. Do you still feel this way?
@@TheScottShepard absolutely. Even more than ever. As a coach in the middle of another transformation I am seeing it once again. Estimation is necessary and if you do not have adequate metrics the people will do a lot of gaming of the system.
I have given your position a lot of consideration to be honest. I see how the estimation game is worthless if people are not dedicated. The truth that I keep observing 8s that the team has to keep each other honest, and it helps when you have a SM and PO that knows a little about the tech stack so they can ride rough shot. Another key thing is to either distribute your team across regions, or at least cycle them into different products. This way they do not get too close and take up for each other when sandbagging. When I was an RTE at Charter I saw the teams in Texas playing and lieing for each other so they didn't have to produce. Once I scrambled the teams, productivity increased.
Sorry I cannot buy into the hype. I have been in IT for 30 years and know the game better than most since I have been in the trenches and at executive levels alike.
@@TheScottShepard I appreciate the follow up. No hard feelings, just different approaches and results.
@@opensourcefreedom9241 honesty is key. The team needs to be empowered and to share a desire to meet or exceed goals. In a big unfocused enterprise this is difficult to expect and it is the failure of management.
I have taken no position on this topic. It would be great to not need to estimate stories, and to do real TDD, and continuous delivery, but those concepts are usually held back by a variety of reasons.
Keep working hard for your teams and I hope you get to make things you are proud of!
Sorry but this video is way too biased... It feels like trainers ran out people to train on previous approaches and they have to come with something to fix to give more trainings/presentations.
Reality is that both techniques are useful if used correctly, both are useless if used incorrectly.
We slice stories when we groom, share understanding and validate this understanding by estimating as a team. I've seen good estimates come out of this approach and a predictable velocity. That's one approach.
I've also seen story slicing and no estimates go wrong, different understanding, devs with free time or with a ticket in multiple sprints. So yes, no estimates can go wrong too.
Ah this is good stuff: can you say more about how NoEstimates can go wrong?