#NoEstimates
ฝัง
- เผยแพร่เมื่อ 17 พ.ค. 2024
- This keynote presents my (and many other's) thinking about #NoEstimates. It argues that estimation is a bad thing, particularly in the Agile world, and presents ways to plan that don't involve estimation.
- แนวปฏิบัติและการใช้ชีวิต
I soft deleted ~70% of our backlog 2 years ago and no one ever noticed. It was amazing!
Or they had already resigned themselves to none delivery
hahahaha
Lol
😀...
@Mark Lindell, you still continue to do soft delete of backlogs?!
You silently removed items in backlog - they didn't notice.
They silently resigned - you didn't notice either.
Fair game I bet :D :D :D
Fantastic presentation.
One of the most valuable videos on TH-cam about software development IMHO.
As Allen says at the end (and I so agree with):
It’s up to developers to get this happening on our projects - management’s not going to understand the dangers of estimating until WE educate them!
Completely agree - but it is a VERY hard sell... on the surface, it sounds so easy, so simple and valuable to estimate...
Any manager should be asked to estimate, how long it would take him to write a 500 pages book. If he asks what about, answer "we don't know yet", but let him estimate the pure work to write some words on a sheet of paper fivehundred times. Take this time for granted and tell him, what the story of the book should be about (a thriller) and the basic plot. And when he is mid-through writing the story, change the perpetrator... this should help him understand, what estimation for a developer is like :)
If the manager is a writer and have written dozens if not hundreds of books before, then that estimate should not be very difficult. Estimates are ALWAYS based on what the requirement was when given. Changing requirements ALWAYS require a new estimation. That is requirement management 101 after all...
If you don't have enough information on what to actually build, then don't give estimation and ask for clarifications. It is the basis of requirement management after all, so if you have a requirement process this should never be an issue.
I've used an example like this but with making an album or film.
Even if a writer has written dozens of books, he/she could still fall into something called a writer's block. So, this is a realistic example.
I think coding is much more complex than that. A better analogy would be write a 1,000 page book, but if you make a typo on any page it could cause your book to be rejected by the publisher. You also don't know what constitutes a typo, or even which grammar the publisher is using, because you are not the publisher.
@@jimiwikmanofficial Estimates are waste. Unless the requirement is something very basic and generic that was done probably at least a dozen times, any estimate is a guesstimate.
I'd love to subliminally play this in the ears of PMs while they slept.
Inception!
My kids on a backseat remind me of the "managers". They constantly asking "when we'll be there?". And the answer is always "It depends on traffic situation. Here is the calulated ETA from navigation, but it means nothing". However the kids keep asking same question over and over again. They dont understand that the only things you can effectively manage are the stops. Maybe dad can drive at a higher speed than he is comfortable with, but it will increase likeliness of an accident.
And all the managers i've seen were those useless "backseat managers", which had no actual means to influence the process, but asked useless questions to reduce their own stress level. And if the previously communicated time of arrival got less realistic, they called the customer and "communicated" to him, like "mom, we'll come even later than i told you last time". And this piece of information reduces the stress level of the "mom", but it also doesn't make the car arrive faster. So the best thing would be to give the customer a means for real time tracking. Which the agile board actually is. This would effectively eliminate the need of reporting home every few minutes.
I keep watching this and watching this video. All my managers should watch this video.
@Abraham Serafino I would be curious to get a link to one of those videos.... ;-)
@@MarkLindell For real..
The whole agile approach as discussed in this talk is build on the idea that the team is highly invested and pushes itself. In reality, there is a ton of boring projects out there staffed with left-over developers and graduates and if you let those people alone, you will have nothing after 2 years. Not everybody has the capabilities to be a Navy SEAL. If you work in a really large company with 10,000 or 100,000 of developers (e.g. in large offshore-centers), a very large amount of them is barely able to carry their own wight. I bet, many projects out there could remove at least 20% developers and the project would not suffer a bit.
The ironic of this speech is that in the background is the logo of amazon, a company known for making their workers work long hours to achieve deadlines
To be fair, Bezos does look like some badly created villain.
I've thumbed up that one myself :-). I have no control over who the conference sponsors are, though.
I think they don't even do this Scrum thing themselves (is either Amazon or Google) and for Intel I personally doubt they do any kind of Scrum ot Agile, since they're a hardware company and doesn't go well.
@@errrzarrr - it’s a shame though as The Mythical Man Month and Soul of a new machine illustrate. One about IBM System 360 and the other about a new processor. Both books deal with agile projects and small teams.
The first video that I found about no estimates that answer how to plan for on time release. Thank you a lot.
I hate those refinement sessions where you spend an hour or so just on estimating story points
This is sooo spot on! I worked with a team a couple of years ago where the project managers were always wanting to 'bag the points' and the team were told that there velocity had to increase every sprint! Total bollocks and resulted in quality dropped and people leaving
@@zealy1369 exactly what I said would happen too, but the same po/pm would fight to get them lowered, which was insane
Bad managers are common. That is why they are called managers and not leaders. Their job is to be overseer and their worth is based on the value they produce and often they use the whip to get it and not the carrot.
We once got a new manager who added in points and made a big deal out of committing to completing a number of points. I worked my ass off for 2 weeks to get a huge project out for the points because it was a bigger task than I initially thought. Literally worked two 60 hour weeks coding 95% of that time to get it done. The next meeting he got on me for trying to lie about how difficult it was and saying it wasn't that much work. Myself and the other engineers got together, talked to his boss, and got the guy fired.
"team were told that there velocity had to increase every sprint" - I worked for a couple of companies like that and the result is always the same : total shitshow and ultra toxic environment.
This is so spot-on, particularly about the role of managers, how most are not needed and those that are needed are a support role for the workers
You would be surprised to know the crap managers deal with on a daily basis :) Especially middle managers have the worst position in the whole company...
Finally someone with a sensible story. Hats off.
The projection model built on counting stories depends on the assumption of a fully elaborated backlog where stories are all "small" (or "appropriately sized"). Now producing that also takes tons of work, and can be considered a waste as there are tons of changes in the backlog. I am not saying this is a bad idea - just stating that regardless of the method, getting projected or estimated dates will have a considerable cost associated with them, and with increasing desired precision the cost will also increase.
If you have 100 big and vague stories and you just start, then you take for example 5 first most important stories and work on "slicing" them to smaller ones. This way you don't waste time on working on all 100 stories to make them comparable size. So let's say that those 5 stories were worked on and became 20.. so you have 115 stories now, and you've done for example 5 small in the first iteration/sprint. You can make a projection out of that (5 to 115). Then you continue to work and make vague stories more specifig which changes the size of your backlog as you go and the prediction date changes as well. Doing the most important things first (which changes as well while we learn about the problem and business) you may actually finish the work earlier without even completing everything from the backlog.
So it takes tons of work, but you do this work only when necessary to progress in the work. And based on this the projection updates. It's live.
The assumption here is (as stated in the video) that the client invests small batches of money for each iteration and makes decisions based on constantly updating projections (for example by throwing out stories, changing priorities, stopping project or getting more people involved). [Customer collaboration over contract negotiation].
The problem with estimates is that the client/manager believes in them, so when you are near the deadline it's already too late to make game changing decisions, because you hold to your belief for way too long until it's too late.
Projection based on counting stories shifts the focus to: what's the next most valuable story I want to be worked on to have something of value when I stop investing more.
At least this is how I understand the talk. YMMV.
True. Estimations should be done on the level that makes sense from a collaboration and financial perspective. You always need some way to know if the value created is motivated by the cost and a prognosis on when it will be completed in case there are other things in the company depending on that development, or other development that might need to push that back or forward in time.
you also take into account the growth of the backlog in your projection, it still holds
this is the most legit guy i have seen on agile...
Estimation does work...for management. They play down the significance and validity of estimates when they want you to make them. And then treat them as real later on. And they know this. And we know it. Or should.
This is one reason why people do startups; to get away from people who think they can control the creative and problem solving processes.
To me, great teams want to create. They want to get into and stay in a flow state. They love collaborating when a problem needs solving. And they love doing their own thing when they know exactly what needs to be done.
They love it when they can streamline things, execute fast and eliminate bugs. They love making a tool that can produce a lot of value with a little bit of user effort.
They love it when a user arrives on a page for the very first time and says "Oh, I get it!" And when the user pushes a button and gets exactly what they expect as a result.
So put them in a meeting. That'll put a stop to all that!
Estimations are always for management to make plans to coordinate efforts across the organization, as well as to keep track of costs for value creation. They are the ones that have to present why development teams should keep existing based on the value they create that always have to be higher than the salaries the companies pay for them.
You can never get rid of that fact because every single developer work withing financial structures.
If you make life more difficult for managers, you will not only risk your job, but you will undoubtedly see micromanage and get disturbed all the time by managers that NEED to know time vs cost at all times. That is their job.
Excellent talk, thanks for sharing!
Thank you for this video. It feels much better after watching it. It showed me that I was not wrong. God knows how many times I have tried to hit my boss when he forced me to come up with estimates.
You mean you tried NOT to murder the boss.
Just because you've found a public speaker that is one the same page as you, doesn't automatically make you right :D You can literally do that with any thesis :)
Great presentation Allen Holub. One comment regarding Lean organization, from my experience it is often used as a way for upper management to control engineering team through direct reporting.
You deserve more subscribers. Especially CEOs. They need what you preach.
This is a fantastic talk thank you!
This is the explanation i was looking for ! Thank you sir.
Wow, thank you! the most valuble video.
I can't stop recommending this video to anybody that works with various teams.
It would be useful to have a bit of a dive on _why_ managers need estimates in the first place.
For example, at least in Europe, the labor law itself is built on time based rules, such as 8 work hours a day, 220 days a year, monthly timesheets and following payments and so on. Furthermore, notices periods form any of the parties is in the order of months.
So the labor cost depends a lot on these parameters. Predictability is important, as the labor force is not that mobile.
This made me sad. It made me realize how great things could be, and how far away my current workplace is from that greatness. Amazing talk. If I ever get a say in how to run a project, I'll definitly put the idea of rebelling against estimates on the table
I hope you get the opportunity to be a Project Leader. It will be interesting how you would implement this, considering your number one responsibility as PL is finance and value creation withing the defined time. I would really like to see your first few steering meetings without a single estimate to make the prognosis against other initiatives...
Thank you, great talk 👍
I love this man.
I've been saying this since the 1990's and everyone mocks me. Now I can tell them Allen Holub agrees with me!
Or they can mock both of us :-)
@@AllenHolub At least I'll finally be in good company. Loved your talk. Will take in more soon.
You know the Fuck Agile websites, right? Mr. Holub said gave the middle finger to Agile without raising his hands.
I experienced several sorts of managers. One sort gives me support to do my work and taking any obstacles from me. The second one use estimates, numbers and metrics to measure our performance and punish us on not meeting them. I also used estimates to give deadlines. This keynote gives me clue what I have been feeling subconsciously for longer time.
You give good examples - the takeaway is that Agile won't ever fix a bad manager. Not doing Agile, ALSO won't fix a bad manager.
I completely agree with every single word spoken in this talk. I myself have been increasingly skeptical and critical about estimates from many years now.
After reading Thinking: Fast and Slow and The Black Swan, it is clear that estimates and predictions simply do no not work. Simple as that. There much evidence in the scientific community in form of research and observation of empirical facts that they do not work. I won't go into the details here because entire books have been written on this topic, but the simple idea is that we don't know about the future and how the countless variables change during a period of time.
If estimates or predictions work only some times, it is random chance. We could as well just toss a coin to decide on how long something will take to complete or how much effort and resources it will require.
As for the hurt story points and estimates cause for teams and projects, I can tell many tales of people closing incomplete cards in their ticketing systems just to meet a sprint deadline, merging broken, untested, subpar code, pretending that the tasks were completed within the allotted time, then creating further cards to do further work.
Or, people feeling destroyed because sprint after sprint some cards are always spilled to the next sprint, cause bosses graphs to look bad, and endless meetings to discuss "how to prevent this to happen in the future", just to have it happen again in the next sprint.
Story points and sprint deadlines are a good way to implement means on how to destroy team moral, bore the hell out of people, and make people lose the sense of meaning by forcing them to do things they know from experience don't work and is a waste of time, life and countless hours of work.
But for people who want to pay programmers less [1], it is a good tool.
1. www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html
The idea that you always work with unknowns does not make any sense. It is true that you can not predict the future, which is why unknowns are always a part of the estimations as additional time. If you can't hit a 90% accuracy with your estimates, then you are either inexperienced, so you don't know how long things take for real, or you don't have enough time to properly evaluate and plan for what needs to be done.
Not pushing back on rushed projects is always on the developer, and you should always write technical debt when code is not of the correct quality due to financial decisions. Providing realistic estimates eliminate this problem almost completely, but it requires you to actually know how to estimate and stop trying to make happy guestimates.
I would love to work at such organisation. I'm always amazed how much time we spend on grooming sessions about estimating things that in the end we even started doing 😂
What you are doing is helping the business side to spend their money wisely. Estimations will show if the investment in time and money spent will generate value that make the investment worth it. Considering that as a developer your job depends on the business making money, that should be a high priority...
This man knows!
Perfect. Start of a new project tomorrow - gonna try it out :) Thanks, Mr!
Did it work?
I completely and utterly agree. The people against #NoEstimates gets bad estimates... but they get bad late or bad software.
thanks for the video! how can we predict completion of an epic that hasn't been started yet, with the help of the cumulative flow diagram? when we don't have any history of how quickly the stories are getting done?
The "count the stories" approach might have worked well because the team was good at estimating equal-sized stories.
You're not considering the fact that if you feel like you need to do that, you aren't using stories & agile correctly in the first place. What should be measured is the value delivered for clients, not the work required to do it.
I say the same since 15 years or so. I seem not to be alone with that.
I've done this myself and it works, but it works when you have mostly similar size, well understood stories
Does the use of estimation tools help in providing accurate estimates? I have always argued that even with the use of an estimation tool it is still produces an estimate that will, and will always be, a best guess.
Really interesting approach
I have never gave a good estimation to my managers...
I would just say estimates are similar to something you say I will score 80 % marks in the final examination.
And then you try to and study your best to achieve that target.
But you get 95% or you get 65%
Even if you score 95%, you are in problem you really underestimated and overdelivered.
Even if you score 65% you are in problem you really overestimated and underdelivered.
The first situation will not always work in the positive note. The L +1 will eventually understand this and will start expecting more and more and will force you bring the second situation which is where you start burnouts, start loosing comfidence and start underperforming as your moral will be down
The second situation will be considered as the performance issue.
Software development is not the smooth journeey like you are travelling in Aeroplanes where time is predictable.
It is like traveling in the bus on the roads where you are very likely to face traffic jams, accidents, signals, rough roads etc…Imagine you dont have any kind of google maps or here maps…
Its like we need to draw the maps on our own..on our brains..
You may get into wrong direction, you may find shortcuts ..but you dont know unless you realise.
Sometimes realisation comes after the problem is solved.(we should have went in that direction , but now we have reached the destination, there is no way to change the path and the quaility of the code is hampered..)
Another example is how can you judge the quantity of water in the well just by looking at it from outside it unless you see the bottom surface?Is it possible?
I will say irrespective of applying the any best possible techniques, still you cannot expect the developers to be perfect at estimates..
Its not about how long it should be how best it can be done.. I would say, rather than seeking the false promises from the developers and trying to fulfill them by making them spend sleepless nights and make them sit for long hours a day, I would say if we concentrate on deliver less , but deliver quality. Customer would be happy to wait ..
Initially code should be as scalable as possible in order to make the future related requirements easy and pluggable.
Eg. I have to develop a JDBC utilty which establishes connection to the various databses configured.
I would have very easily done that within 30 mins by establishing the connectivity by hardcoding each and every step without caring for future connections.
But what if I make the code scalable by introducing the connection factory and pass get the desired connnection by passing the 4 properties in future?
It took me 1 hour instead of the 30 mins in first approach, but for every future databse connections, it took me hardly 5 mins ..
So 30 mins for every connection like for 5 connections, it can take 150 mins vs 60 mins for 1st connection and 5 mins each for evey every subsequent connection to different different types of databases like 60 mins for 1st connectivity + (4*5 ) = 60 +20 = 80
So which approach is good ? Time or Quality?
Obivously, better quality code would help you achieve the targets better in the future even at the good pace.
It will be better if target is quality and code scalability rather than sitting sticking to the said time target and achieving the false promises.
Fulfilling the false promises will result in false deliveries and false happiness.
So I have the counter question for you, how can you underestimate the power of code quality and code scalabity just to fulfill the expected estimates?
So instead of ‘Say and Deliver’ I would follow ‘Deliver and Say'!
I train my teams to use story pointing to discover impediments. Whatever is blocking or slowing down the story from being done usually falls into one of four categories, Process, Scope, Unknowns, or Communication. If the story is large in scope it needs to be split into smaller stories. If there are unknowns then plan a spike for the iteration instead of the story. If there are communication requirements to the customer or another team then plan a meeting instead of the story or insist the 3rd party join the coding session. All other impediments left are usually around process. These are the constraints that limit flow and are the only things that can theoretically "speed up" development by removing them. So for me and my teams story points aren't for estimation, they're for evaluating impediments and implementing solutions. The goal is then to have every story be the same point value which leaves us with story counting as the way to project.
So more akin to a Kanban?
That sounds interesting, and my question is why you use Story points for this instead of just impediments?
Because it's all BS abstraction that are necessary for these agile coaches to have job security.
Fantastic presentation. Very few comments for a great video like that.
I had a come back one time. Some asked me for a estimate that was trivial, not even worth estimating. So I paused and thought about it and said “Oh 47 seconds.”
Thank you
My workplace used to multiply story points by 4 to get a number of hours. Took a year after joining to convince them to stop doing that
This dude really knows what he is talking about
it's great, counting sliced works are sufficient for projection & minimize wastes with estimation
The one big pushback I've seen from management when someone have suggested no time estimation, is that sometimes projects are sold for a fixed price and management can't offer a price to the customer before having a time estimate.
Wat would be a good comeback to this argument? Is this type of pricing model just not a good way to sell software?
This just reminds me of what Eric Brechner says in his talks about Kanban. Basically what you do in the model he teaches is break things up to chunks of roughly the same size, do your best to maximize flow, measure how many get done in the measured period of time and what falls in your lap is a rough projection. Yes, obviously the process of breaking things up into pieces of roughly the same size is estimation but to me it sounds somewhat doable. So if the stories are roughly the same size...
Definitely doable :-). At least I've been doing it for a while and it works great. Frankly, narrowing all your stories down works even if you still insist on estimating. I coach Scrum teams to do it, too. Not only is it much easier to gauge the work, but breaking up a big story into small ones uncovers all sorts of low-value, unnecessary work (which you then don't have to do!). I just came across a set of great planning-poker cards (estimation.lunarlogic.io/). There are only three cards, labeled: 1, NFC (No...Clue), and TFB (Too...Big). Bought several sets to hand out to Scrum teams :-)
I once had a manager who told me he could account for unknown unknowns.
What a superpower. Thanos + his fully equipped gauntlet would be mad jealous
Allen, I love your talks and wished there were more people in my company who have seen it. However I have one question regarding projections and the size of the backlog. If you say that probably 70% of the backlog could be deleted as we don't know yet if the stories are correct at all, how can I then do a projection? In theory the top 10 items are the ones where a projection might be useful, but then we're talking about probably one month of work, but not the whole project. Would be happy to hear your thoughts!
This only happen if you mix strategic and operational items in one backlog. If you understand the requirement process then you know that only actually decided requirements end up in an operational backlog and that backlog is reviewed every week, or at least every sprint, before you put things into the next iteration.
Only if you don't have a proper requirement process will you have backlog stuffing, and even the team should remove things unless it is likely to be included in the next couple of sprints. The business need should be recorded elsewhere anyway, as that is not a requirement.
Good. Another dynamic here that totally supports your POV is that properly written stories all end up being close to the same size anyway. They have to be large enough to represent complete, vertically-organized, user-valuable functionality, and they should be small enough to fit into a single sprint. Large stories need to be thinned up in some way so that user value can be chronologically delivered at a consistent pace. So if all the stories are about the same size, why not just count them up? Done. Now of course that just kicks the can down the road a bit. Now you have to spend time writing and splitting your stories, but that IS valuable to the business because it gives you 1) Prioritizable work, and 2) Chronologically deliverable work leading to earlier feedback.
Don't DO agile, be Agile! Thanks for the vid. Great explanations. Question - What are your recommendations on those projects/programs that don't have an actual deadline?
Allen, I like the idea of using story count for prediction 👍🏻 and somehow time estimation never appealed me. But story sizing using story points helps team to get to a common understanding and would always prefer that be done.
I agree with your idea of not doing too much too early (too much planning for an unpredictable) but a complete NE is no way.
What a great presentation. I love how you are cutting through the bullshit, well done.
0:43 estimates are guesswork until registered by manager-type-person then they become a message from the future and any deviation from the estimate must be explained at the point of a gun
Really like this. Do you have an alternative that Big Corporates will accept? I need to know. :)
Probably not. I've pretty much given up on Big Corporates when it comes to agility. They're just not interested in doing anything other than using the word "Agile" in their advertising. There are a few glowing exceptions, but they're as rare as hen's teeth 😄
I wonder what data is the "100 item backlog" story starting at 17:00 based on. Sources would be nice to mention, even if it's just "my personal experience".
+Allen
how do you make projections at an early stage of a project when a couple of stories at the bottom of the stack are low priority and are, therefore, not as small as the higher priority stories?
If you break down low priority epics at an early stage, it's waste. If you don't break them down, how do you include them in the projection?
The stories at the bottom of the stack don't matter much---they'll probably change considerably before you get to them, if you ever *do* get to them. Also, the stories-per-period metric (which is an average) settles down pretty quickly; typically, within a few weeks. That metric carries over from project to project of course, so you don't even need those few weeks for an established team. (And you should not be splitting up teams simply because a project is over. That's a serious dysfunction from an Agile perspective.)
So, the main points are: (1) You're working with averages, so the size of an individual story doesn't matter much. (2) You'll probably never get to the stories at the bottom of the stack because, odds are, new stories that enter the backlog will be more important. I wouldn't worry much about them. (3) If you don't have many stories in the backlog, spend a few minutes and "narrow" them (reduce their scope) so that your averages will be more fine grained.
So we went from Time -> Story Points -> # of Stories. Cool.
In real terms, how is # of stories any better? I wonder. 👀👀👀
I do agree that estimations are “guessing” but isn’t velocity a part of scrum and agile?
How would you have any projection in any real agile environment when you are creating just enough of a product backlog to start working on a couple of iterations? How would this work with a 6 month+ projection since you don't want to build a backlog of stories for 6+ months.
Interesting concept, he covered one issue with the perspective which is project feasibility but in my experience, what the business often need to know cost.
Can we afford this project? Do we need to re-budget our business priorities? Do we need to hire more engineers and so on.
Developer may be engineers but also service providers like lawyers and lawyers define their costs as time. The presenter explained how we can ignore time estimates, but what about the real issue cost?
You can't predict that and you should stop, that's the whole point. It will cost exactly what it costs to develop and guessing that upfront is always going to fail.
You missed the point.
The "roll" of management..
are we willing to be hired by 2 weeks basis and see how we work then extend another 2 weeks of our employment contract?
I liked this presentation at first. Mr Holub gives a great and very passionate presentation. I like that.
But really this is about #AntiEstimates (a tag that doesn't exists) and not about #NoEstimates. The latter is about exploring alternatives and doesn't say "Don't use estimates", but rather "Use estimates if you cant find something that is better; here's a few things we've tried".
I think there's a difference.
Great presentation - thanks
+Marcus Hammarberg: I suppose I am #AntiEstimates :-), though of course you could cast the projection techniques I discuss as a kind of estimate. You're absolutely right that #NoEstimates is more about having the conversation than coming up with a "solution," however. I see this talk as a part of that conversation. Being a practical-minded guy, I've layed out my solution, but it's certainly not the only approach!
+Allen Holub Thanks for the comment and just to restate; I liked the presentation - very thought-provoking. Thanks
If you watch the video again at 1:40 you will that got the wrong picture. This video allow me to say it needs an open mind and its hard to grasp when we are used to do things in a certain way. As humans we don't really like change.
Hmmm. I'm willing to give it a try but it seems to be based on people/teams that don't don't understand story points. From my experience if done properly sizing works pretty well. Story counting would seem to have just as many issues (waste) as sizing - doesn't the story size matter? What happens if they are wildly different in size? What about the sizing proviso that if a story is bigger than x you probably don't understand it? I'm not sold
Thin vertical slices is a best practice. In doing so, the items tend to be consistently small. Even if there is variation, a few outliers will obey the law of averages. The same is true for changes in capacity. Then one can apply the cone of uncertainty to project a range of what is possible which is more realistic than any hard number or long-range project plan, SWAG estimate. HTH
@23:00 restated.... "The developers at the race car drivers and the managers are the pit crew."
From my experience: Estimation is most accurate when it takes more time then solving the ticket.
Is that counterproductive? Ahhh! Sarcasm!!
Good one!🥂
My team lead said this once: I could finish the ticket now (during the backlog review meeting LOL).
Allen, I wonder how you currently view your explanation from 26:39 onwards. You compare the number of remaining stories with the number of done stories, in order to project when we might release the software.
In other talks I hear you note that backlogs that are more than a few items large can be considered waste (and I see your point). I wonder how we can still use this method of counting, even if we keep our backlog small (let's say 10 items or so)?
you are my people
This talk, while good and true about estimations, takes for granted the existence of a customer, that the software company (vendor) already has a customer with a backlog and it's just a matter of executing it. The topic debated what goes in the sales negotiation, and what it takes for that customer to sign the contract.
To make an analogy, I am a customer and my MVP is a fully functional car. Anything less than that is not valuable for me. As a customer, before I sign the contract, I would like to know how much the car would cost and when would I get it. From this presentation I understand that as a customer I should be happy to get a response on the line of "well, we can deliver the first door in a month, then another one after another month and the steering wheel after another month and so on. Oh, and we don't really know how much would cost at the moment, but we'll give you a projection after we deliver the first door. But as we're agile, we can guarantee that you will have the car, someday". From my past experiences no customer signs a blank check. I'd love to learn of a better way than committing to the customer with some estimated date and cost and then making everything possible to meet it?
Allen skimped over the projections part in the presentation, which seemed the most important. And the projections seem to go back full circle to time estimations.
#noestimates isn't a methodology, it's a labor movement.
Even with forecasting, user stories are still used in the example. Isn't having user story points imply we are still estimating?
That's what it is. We still playing wizards game here 🧙♂️🔮🧿
Amen!!!
15:46 - How do you give a price offer to a customer who has a bunch of things he wants to get developed (like redesigning a website or some admin functionality enhancments) and he is not interested in trying stuff out for one month and then reiterating tickets, he just wants to know the total cost so that he can ask multiple companies and compare prices?
As I have gotten more into Lean Agile i've been using cumulative flow, control charts and monte carlo simulations , mostly as a hobby as I'm not yet ready to replace my old world view, but i'm compelled. How do you know you have all the stories is my question? And if most of your stories at the bottom of the backlog are nonsense, how can you trust that number?
I had the exact same question.
You don't need ALL the stories. All you need is the rate of change of added stories and consumed stories (do not log defects as stories...more on this later). If it helps, you can treat the backlog as candidate stories...until you associate them to a release. The planning that you saw on the screen is around a release, with a fixed number of epics (don't change the epics of a release if you can help it. This will simplify your scope and also help prevent your team from getting "whipped by WIP"). The accuracy of "When you will end" will get better and better the more sprints you do, but you need at LEAST 3 to have some sanity and confidence that your 2 rate of change and where they intersect are "good enough". Couple tips here: #1 do NOT log defects as stories they will confuse your backlog and you. When a defect is discovered (lets say through exploratory testing as hopefully you have automated TDD, the defect is validated from your product owner or the team that is actually a defect in the scope of that story....and then you fix it....immediately. Defects take the highest priority, the team stops what they are doing and you fix it. #2 Not having defects in your backlog will provide better data for your rates of change from stories. #3 To account for "time to handle defects" just reserve %20 of your teams capacity for defects in sprint planning. So if your team can typically only handle completing 5 stories in a sprint....cool, they only commit to 4 stories so they can predictably take care of defects.
I also wonder about the same thing and unfortunately I cannot answer it, but I want to note: if you are not sure you can count the number of stories, there is surely no point at all in estimating points/time for them.
Very interesting, I liked it a lot.
I miss something. It is OK to count stories, but sizing the stories is very important too. I worked in a company where the size of a story was huge, so having something done took a while and having this projections was not possible in a short time.
"Take the torch and speak with the bosses"... I do not know how to do it in a company that resists to change and where people above know better that developers how to do the job.
A story should not be large. Break it down.
@@vladpredovic6956 The moment you assessed the story as large, you did estimate, be it in T-Shirt: "This story is L". The whole #NoEstimates breaks as it is unbalanced message with radical rhetoric. People need some common vehicle to communicate simplified understanding in this case of a story, just like you have said "story should not be large", but what large means? What it in my opinion it is not large but small? That whole conversations is underline an estimation of story size, a guess.
What we should advocate is rather to no use estimations for planning tool, nor for making crucial decisions, or being aware of how reality unfolds. For that predictions methods mentioned be Allen Holub are far superior.
You have deadlines because somebody somewhere told a customer "Yes, we'll have it by that date." When the real conversation with the client should be along the lines of "we've evaluated that as our next highest priority and will be working on it." And then giving the team the freedom and authority to only work on that thing next (not 5 other things too), and trust that team will be giving their best effort (if you can't trust that, either different management, different processes, or a different team is needed), but you can't make people turn out better work by giving them timelines out of thin air.
In my experience, and I don't know how widespread this is, it's not that we don't know how to make good estimates, rather it's we are pressured to provide overoptimistic estimates to get the project/job approved by the boss/client. What I do, is give a range, that usually has the clients budget close to the lower bound, my honest estimate in the middle, and the "top bound" the delta between the two inversed. e.g. best: 2, likely 5, worst 8. The sales people always quote the lowest bound, a few months down the line I point them the upper bound and tell them we landed within the range :D
EDIT: The way I get there is I ask the team how much each development item would take if all went well, and if all our assumptions are wrong. These become the bounds, assuming they sit at -2σ and +2σ, and the mean I label as most likely.
Let's say we agree to Scrum in Agile and we do not do estimations. Now, Team X; delivers 4 stories in 4 weeks then in the next 2 weeks they deliver 4 stories again. Don't we think that in other to eliminate the time we need to keep time constant? For Instance, like in Scrum, we have fix timeframe that the team has to chose to run their Sprints and if this timeframe changes anytime within the project delivery it certainly would affect the trend in the story count. My suggestion would be, let stories be Placeholders of a problem worth Solving. Get the team to discuss the approach to solve each of the problems, after agreeing on the approach, break down the problems into tasks that could be completed within their day's capacity. Then at this point counting the stories would eliminate the effect of time because what the story count would depend on will be Tasks completed as time has been brought down to a constant of the developer's day's capacity. What do you think?
How long should story take?
This is great, except I didn't get a very clear answer to how to answer the questions:
1) When do you think you can have this done by?
2) We'd like to launch this year, do you think it's possible?
How do we respond to managers who ask that?
Rocky, One of the problems is that's not an agile way of thinking about things. When presented with a time box (anything from a sprint to a year), the question to ask is "how much value can we provide in that time period," and of course, you learn as you work, so the things you'll be working on change. Even the Scrum Guide says that you should work that way. Your first question presupposes that you can entirely define a project up front. An agile approach says: lets build the smallest, most minimal thing we can get away with first, then based on actual feedback from actual customers, we can incrementally expand it. So, you get a set of stories, narrow them down to a day or two, and then work on them in order of value. "This," then is the next story. You'll be done with it in a couple days.
Re your second question, that's the point of doing dynamic planning using a cumulative-flow diagram. It's making a projection based on actual measured progress and the size of the backlog, and not only answers your question directly, it gives you options if you don't like the answer. If the projected date is too far into the future, you can adjust scope and see the impact on the diagram.
If your managers have fixed both scope and time, and they're not willing to add teams, that's a classic death-march, iron-triangle situation. That's just bad management performed by people who don't understand the fundamentals of business, and there's no solution to that particular problem :-). In agile projects, scope changes constantly. That's what agile is about, accommodating changing scope.
Thanks so much for your reply. I will take your advice to heart. I do have an unrelated question: is it possible to take the number of the stories completed against the amount in the backlog per the last three sprints from one project and apply it to a different project from another customer but the same team? Or must we always start out not knowing then, once we have 3-5 sprints done, we can project the rest of the timeline?
Well, your average number of stories completed per week will probably transfer, assuming that you're not changing technology or team composition. The main thing is that, to transfer the metric, you need consistency. On the plus side, I've found that the average "settles" pretty quickly, so if you get it wrong at first, the number will adjust within a few weeks.
Nodding so much in agreement that my neck hurts!
10th time watching
Had anyone done the story mapping method?
No doubt that the talk and the presentation was great. I really liked this #NoEstimates, but i still feel it is incomplete. It is like we are only discussing the problems in different ways, models and techniques, in every talk and articles over and over again (lol, i am doing the same rn). Those projecting techniques are good too, but when the client asks you 'by when are we up and running', and i guess we would reply them saying 'we will let you know when we are done, when we are done'. May be i am naive, just started as a junior developer. I believe client will not wait unless we provide them with all the dimensions and time being one of them. If i misunderstood something please let me know, like to learn and grow.
Why are the Managers there? Managers should be able to manage clients and not try to manage employees...! If you look in google maps, even it is not able to predict the right amount of traffic comming on the way. It just shows the current status on the map..! If anything changes the predictions too change..!
"When are we done?"
"We can release now if you are happy with the feature-set that is available"
@@defeqel6537 hi thanks for sharing that. The question asked "when are we done", seems like it was asked after some development was made. But what if it was asked in the start?
@@9paradox The honest answer is "we don't know", but I realize many customers don't like this answer. The presenter mentions in other comments the need to also educate clients on agile practices.
If you play the video from 24:30, Allen discusses how to solve that problem. Given the current state of the backlog, and the current RATE of stories being implemented, you can reliably tell the customer when the product will release. You then have a few choices: a - kill the project; b - reduce the backlog; c - add more resources to change the velocity of the story implementation; or d - accept the date. The point at which the backlog line and the story implementation line intersect is essentially your date of completion.
Is it still applicable in 2024?
IMO, the problem here is this fixation/discussion about ‘management’. A lot of developers/teams pitch themselves against ‘management’. And this disfunction/battle will be seen (when we get past it) as similar to the ‘throw it over the wall to ops’ that we had prior to DevOps. What we should be doing is focusing on what the ‘Business’ needs - and the problem we have with larger orgs is the layers of translation between ‘the business’ and the people who ‘do the work’. The solution is, IMO, to remove layers of management, connect empowered-high-functioning dev teams into the business, and clearly set the direction. We see this in startups. What we need to do is scale the startup mindset - this isn’t Agile processes though, it is an agile mindset based on domain / business understanding.
Fibonacci is used other than normal sequence because the difference in number is well reflected in human mind for Fibonacci
Never been in a place where the bosses, the risk takers, told me 'hey take your time, you delivery when you deliver'.
Bosses are risk takers? Wat?
The problem I have with this is that you require people to accurately estimate sizes of tasks relative to each other.
You just shift the estimation.
Now you need to write stories of similar sizes instead and estimate if that is the case.
I see the value and will try and use it.
But it still requires a lot of work
I think that story points have a great value, but not for forecasts.
Namely: during planning poker, when all devs reveal their numbers, a discussion is triggered with the outliers. This makes for knowledge sharing.
but then the method is somewhat of a lie: people are told that story points measure something meaningful and it's all too easy for managers to interpret them as such regardless of the side effect that performing the task invokes discussion. indeed simply breaking down tasks as a group without resort to story points will be just as fruitful for one will notice where there is not enough information to reliably predict anything. the devil is always in the details.
Where was this recroded?
Always under-promise and over-deliver!
Well, estimates allows our team to get a common understanding of the work that is to be done, but our teamsmembers change once in a while (8 total, 2-3 changes per year)
Yeah, I'm new to this whole thing but I think if we had more clear descriptions of what exactly the business side wanted, specific requirements, we wouldn't need estimates at all.
The correct answer to estimates is always "ten years". Will it really take ten years? Of course not. But if take longer than estimated, this is always a huge problem. It's never a problem if you are done early. So with an estimate of ten years, you will always be done early. See, there is a fundamental truth about all developing processes: You can either define the end of project by a feature set, then the project is done when the feature set has been reached but it is unknown how long that will take. Or you can define the end of a project by a time frame, then the project will end after a given amount of time but it is unknown what feature set you will get up to that time. But what you cannot do is defining both, feature set and time frame, as that will almost never work, that's only wishful thinking and in the end either condition won't be met. I call this the Heisenberg Principle of Development. So make up your mind what is more important to you, when the project is done or what feature set it will have and then go along with it. As the video says, if you are unsure, set smaller goals. Go with a small feature set and see how long that takes or go with a short time frame and see what you get, then adjust your future decisions accordingly.
I wonder if software developers working for the Chinese Communist Party (CCP) are told to provide estimates? Are they told by management when the project deadline will be upfront and /punished/ if it’s not met?