#NoEstimates

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.

[@MarkLindell]

I soft deleted ~70% of our backlog 2 years ago and no one ever noticed. It was amazing!

[@ricmorris9758]

Or they had already resigned themselves to none delivery

[@AjayKumarofficial]

hahahaha

[@MR2SpyerJournal]

Lol

[@shubhodaye2152]

😀... @Mark Lindell, you still continue to do soft delete of backlogs?!

[@kahnfatman]

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

[@HealthyDev]

Fantastic presentation. One of the most valuable videos on KZbin 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!

[@thygel.122]

Completely agree - but it is a VERY hard sell... on the surface, it sounds so easy, so simple and valuable to estimate...

[@honkderhase8724]

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 :)

[@jimiwikmanofficial]

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.

[@chrissiegel1094]

I've used an example like this but with making an album or film.

[@shashank.c]

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.

[@karmatraining]

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.

[@ForgottenKnight1]

@@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.

[@BryonLape]

I'd love to subliminally play this in the ears of PMs while they slept.

[@kahnfatman]

Inception!

[@knighjl]

I keep watching this and watching this video. All my managers should watch this video.

[@MarkLindell]

@Abraham Serafino I would be curious to get a link to one of those videos.... ;-)

[@RickBeacham]

​@@MarkLindell For real..

[@vanivari359]

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.

[@orange-vlcybpd2]

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.

[@bapluda]

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

[@theblackhundreds7124]

To be fair, Bezos does look like some badly created villain.

[@AllenHolub]

I've thumbed up that one myself :-). I have no control over who the conference sponsors are, though.

[@errrzarrr]

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.

[@portlyoldman]

@@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.

[@harri00413]

Finally someone with a sensible story. Hats off.

[@arghallum]

The first video that I found about no estimates that answer how to plan for on time release. Thank you a lot.

[@urbanmetal7802]

You deserve more subscribers. Especially CEOs. They need what you preach.

[@mrmaxwell0701]

This is the explanation i was looking for ! Thank you sir.

[@eshgholah]

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.

[@kahnfatman]

You mean you tried NOT to murder the boss.

[@marcinmisztal2884]

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 :)

[@albeit1]

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!

[@jimiwikmanofficial]

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.

[@tk5782]

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

[@tk5782]

@@zealy1369 exactly what I said would happen too, but the same po/pm would fight to get them lowered, which was insane

[@jimiwikmanofficial]

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.

[@simpleman3246]

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.

[@ForgottenKnight1]

"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.

[@BladeTheWatcher]

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.

[@koh-i-noor123]

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.

[@jimiwikmanofficial]

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.

[@andrewdunn3983]

you also take into account the growth of the backlog in your projection, it still holds

[@AlexanderWhillas]

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

[@jimiwikmanofficial]

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...

[@RPoltavchenko]

Wow, thank you! the most valuble video.

[@SimonRobins1978]

This is a fantastic talk thank you!

[@MikeStock88]

Excellent talk, thanks for sharing!

[@patrickrodies6111]

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.

[@hayderimran7]

this is the most legit guy i have seen on agile...

[@7th_CAV_Trooper]

I've been saying this since the 1990's and everyone mocks me. Now I can tell them Allen Holub agrees with me!

[@AllenHolub]

Or they can mock both of us :-)

[@7th_CAV_Trooper]

@@AllenHolub At least I'll finally be in good company. Loved your talk. Will take in more soon.

[@kahnfatman]

You know the Fuck Agile websites, right? Mr. Holub said gave the middle finger to Agile without raising his hands.

[@skyzhangty1]

I hate those refinement sessions where you spend an hour or so just on estimating story points

[@DaveNicholas]

I completely and utterly agree. The people against #NoEstimates gets bad estimates... but they get bad late or bad software.

[@SeelkadoomPL]

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

[@jimiwikmanofficial]

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...

[@mateuszgepert2831]

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 😂

[@jimiwikmanofficial]

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...

[@mihaiungureanu3370]

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.

[@FernandoBasso]

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

[@jimiwikmanofficial]

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.

[@tomaskulhanek7936]

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.

[@songsformydaughters937]

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.

[@MarioRossi-sh4uk]

I love this man.

[@moristar]

Perfect. Start of a new project tomorrow - gonna try it out :) Thanks, Mr!

[@k3ys]

Did it work?

[@nekrivonozhko]

Thank you, great talk 👍

[@luisrueda6109]

This man knows!

[@benpurcell591]

I've done this myself and it works, but it works when you have mostly similar size, well understood stories

[@AlexandraBondareva]

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?

[@gravekeeper4601]

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.

[@pankajshet1070]

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'!

[@hellbroth]

What a great presentation. I love how you are cutting through the bullshit, well done.

[@UjjwalPrakashSinha]

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.

[@coco1979ka]

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!

[@jimiwikmanofficial]

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.

[@centerfield6339]

The "count the stories" approach might have worked well because the team was good at estimating equal-sized stories.

[@kspfan001]

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.

[@Cyproterjoan]

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

[@skaraplis]

This dude really knows what he is talking about

[@szym1]

Fantastic presentation. Very few comments for a great video like that.

[@ElectricTune]

it's great, counting sliced works are sufficient for projection & minimize wastes with estimation

[@Jokikiolu]

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?

[@andishawjfac]

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.

[@ProgrammingMadeEZ]

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.

[@vikramkrishnan6414]

So more akin to a Kanban?

[@jimiwikmanofficial]

That sounds interesting, and my question is why you use Story points for this instead of just impediments?

[@pyrocentury]

Because it's all BS abstraction that are necessary for these agile coaches to have job security.

[@MarcusHammarberg]

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

[@AllenHolub]

+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!

[@MarcusHammarberg]

+Allen Holub Thanks for the comment and just to restate; I liked the presentation - very thought-provoking. Thanks

[@hellbroth]

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.

[@nyrtzi]

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...

[@AllenHolub]

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 :-)

[@kdietz65]

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.

[@houssemzaier]

I have never gave a good estimation to my managers...

[@jensBendig]

I say the same since 15 years or so. I seem not to be alone with that.

[@toshaliveoak7928]

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?

[@generic_programmer]

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?

[@Rocky1138]

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?

[@AllenHolub]

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.

[@Rocky1138]

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?

[@AllenHolub]

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.

[@CarlosArcediano]

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.

[@vladpredovic6956]

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.

[@dbloyd2]

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.”

[@tanit]

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?

[@dmngllghr]

I had the exact same question.

[@BrasingtonAssociates]

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.

[@benedux]

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.

[@goliateros]

From my experience: Estimation is most accurate when it takes more time then solving the ticket.

[@errrzarrr]

Is that counterproductive? Ahhh! Sarcasm!! Good one!🥂

[@kahnfatman]

My team lead said this once: I could finish the ticket now (during the backlog review meeting LOL).

[@9paradox]

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.

[@pankajshet1070]

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..!

[@defeqel6537]

"When are we done?" "We can release now if you are happy with the feature-set that is available"

[@9paradox]

@@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?

[@defeqel6537]

@@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.

[@gergisKhan]

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.

[@kkrac78]

+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?

[@AllenHolub]

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.

[@thevaf2825]

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.

[@Jedimaster36091]

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.

[@MarkLindell]

@23:00 restated.... "The developers at the race car drivers and the managers are the pit crew."

[@TheChillBison]

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.

[@Bobesboy5724]

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?

[@ekted]

Amen!!!

[@pedrosalazarortega6375]

Thank you

[@Lee-qj4hk]

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

[@corsaro0071]

Really interesting approach

[@geehaf]

Really like this. Do you have an alternative that Big Corporates will accept? I need to know. :)

[@AllenHolub]

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 😄

[@matthoffman6962]

I do agree that estimations are “guessing” but isn’t velocity a part of scrum and agile?

[@FlaviusAspra]

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.

[@elcapitan6126]

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.

[@ericpmoss]

I once had a manager who told me he could account for unknown unknowns.

[@errrzarrr]

What a superpower. Thanos + his fully equipped gauntlet would be mad jealous

[@roelesch]

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)?

[@petewilliams2215]

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

[@scrum532]

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

[@SuccessinTech]

So we went from Time -> Story Points -> # of Stories. Cool.

[@errrzarrr]

In real terms, how is # of stories any better? I wonder. 👀👀👀

[@paulkienitz]

#noestimates isn't a methodology, it's a labor movement.

[@BGivo]

The "roll" of management..

[@camshaft30]

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".

[@sherwinsoriano4352]

Even with forecasting, user stories are still used in the example. Isn't having user story points imply we are still estimating?

[@errrzarrr]

That's what it is. We still playing wizards game here 🧙‍♂️🔮🧿

[@Zutraxi]

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

[@arungopi2105]

Fibonacci is used other than normal sequence because the difference in number is well reflected in human mind for Fibonacci

[@felipecordoves573]

I am agreed with pretty much everything Allen said here, estimations are waste (my teams have been working with this counting stories notion and MonteCarlo predictions), but... we can not eliminate deadlines. We always have those, projects have limited time and money. I did not entirely understood his point regarding deadlines, if someone could shine a light here i would appreciate

[@ragunathjawahar9760]

Allen does not talk about eliminating deadlines. Deadlines are necessary and that’s why he is proposing to projecting early on so that you can either add more people at the beginning of the project or kill it sooner than later.

[@jamesanderson6882]

I have been saying this for years. Sad I only have one up-vote. great video.

[@momchilbrashnyanov7454]

He gets to the point at 24:29. Valid idea after that, but you need to make sure that the backlog is properly managed and stories are split in a good way (so that there are no huge stories increasing the risk).

[@hinchan1782]

are we willing to be hired by 2 weeks basis and see how we work then extend another 2 weeks of our employment contract?

[@pankajshet1070]

I see one solution to the estimation.! You become more and more sure about the time as and when you come closer to the solution. If your journey from source to destination is 10 km. You may not be sure how much time will it take to travel 10 km at the start of journey..! But you start getting idea when you reach 5 km at least you become more confident than the start. Still you cannot predict time accurately. But the chances of accurate prediction is improved than at the beginning? You still keep your prediction to yourself and keep travelling until you are more sure. You travel 3 more kms you become more sure.. At this point of time, you can start predicting and are pretty much confident than when you were at the half of journey...! You can give the rough idea to the client. and travel ahead, towards the destination. When the Journey remains 1 km, you really get fare enough idea and while travelling itself we say we are reaching in 10 mins time or so.. when we are sigh of 500 meters we are 99% sure of reaching the destination within 2 mins time as we can actually start seeing the destination. 1 % is still unpredictable, anything can happen, your tyre may be punctured, you might have to face the accident, your might meet your friend, anything may happen! But we can very much guarantee as and when we reach more and more closer to the destination. So we can give the client rough idea when the 25% of the work is left and we can take roughly 2 days to complete. Uncertainty needs to be taken into consideration. Client can only be given 99% surity when 2% of work is pending. and 99.5% when 1% of work is pending.

[@edwinwiancko322]

My (Ed's) opinions: - You have to listen carefully to how Allen is using the terms "estimate" and "projection." - - When he says “estimate” (which he views in a negative light) he seems to be specifically talking most often about story points. - - When he says “projection” (which he views in a positive light) he seems to be talking most often about a setting release target date. - - Annoyingly, many times he will use the term ‘estimation’ in a loose way. For example he asserts “Estimation forces people to work overtime.” - I agree with Allen that a team can do a very similar job of estimating, oops, I mean *projecting* a release date if they: - - get all the stories down to about the same size and - - know (or learn) how many of these stories they can do in a sprint - - Sure. I actually did this with one of my teams for a few months and it worked fine. (The work lent itself to being broken down into small, similarly sized pieces.) - In most cases, however, some stories are going to be harder / take more effort than others. It’s useful to know that. - The biggest problem I see with estimates/projections in general is not that they are “always wrong,” “hard to do,” or “provide no value to external customers”, but rather the biggest problem is that it’s hard for a team team to elaborate or uncover *all of the scope* when *creating* the estimate/projection. I call this "unelaborated scope." (My term. You can credit me with coining that phrase.) This “unelaborated scope” can be measured. I would suggest you measure it for each team and each release. By everyone transparently knowing that the team tends to miss X amount of scope when they project a release, the team can make their estimate a better one.

[@manishm9478]

Thanks, these are good points. I was also confused when Allen started talking about projections. As an entrepreneur i have found any sort of long term projections are misleading and wasteful. And if you set a release date, you're back to deadlines and overtime 🤔 I used to work as an electrical engineer, and could estimate my design projects quite accurately - often within 10% accuracy. Then i switched to software engineering, and would be out by 50% or more. It took me a while to realise this was partly due to 'unelaborated scope' as you call it, because I didn't have enough experience to know what the project would entail.

[@alzaimar]

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)

[@riccardoatwork5291]

Maybe we could say that (copyright Eisenhower): "Estimates are useless, but estimating is indispensable" ? :)

[@AllenHolub]

Riccardo. Many people throw that quote at me. They're all entirely wrong, at least when it comes to software. Leaving aside the obvious point that you can think deeply about a problem without doing any estimating at all, the focus when you're estimating is wrong. The usual estimation process involves guessing the tasks required to build something, assigning times to each of those tasks, then adding the times together. That process zooms your thinking away from the problem deep into the implementation. Implementation-level thinking is not nearly as valuable as problem-level thinking, however. In other words, thinking at that level is just a distraction.

[@riccardoatwork5291]

mmm.. I will think about it... one thing is sure, though...it s great to be able to take advantage of your insights and experience for free and without even having to get off the couch :)

[@carolceg]

I think it may be good for some contexts. However it feels like a superficial solution for a deeper root cause. Maybe we should analyse why, what and how metrics are being taken, why is your manager believing they are written on stone and so on. Just cutting estimates may not be a solution in specific context. We'll have to test, wait and see.

[@deanboman]

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.

[@romuluslucina]

you are my people

[@brando8314]

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.

[@cowhidemusic8904]

Always under-promise and over-deliver!

[@mikeparker6580]

Great talk, however I think this concept would work better if it was less confrontational, and more simply about suggesting an alternative process. "#ProjectionsNotEstimates" would be preferable to me. I'm not of the opinion that managers are useless but I think they are more likely to be useless if they are not close-knit, aligned members of the team. One final thing, I have been in many projects where the scope line is not linear but curves upwards as you reach the end of the project. I haven't researched enough to conclude why this happens, but it's certainly a common occurrence (especially for larger projects). Hence, I prefer instead of simply using 2 lines and giving an exact date, give optimistic and pessimistic lines for both scope and velocity, which gives a rough range of possibilities for the business, and those lines should be further apart, the more uncertainty there is. The reason I think that the level of uncertainty is a useful thing to show, is that you can choose to prioritise work that is lower priority in terms of customer value, but reduces uncertainty and can increase the data around whether or not to cancel the project, add more people, etc. It also allows management to look at differences across teams in terms of uncertainty and can kickstart interesting conversations about how some teams tend to have high/low uncertainty and why.

[@AllenHolub]

Thanks Mike. I've seen the line and the CFD curve upwards, as you describe, in shops that aren't fully agile in the sense that they're still doing a bit (to me) too much up-front planning, so when they approach a deadline, they work harder. (The fact that you have "managers" implies that there's still some waterfall thinking in play somewhere.) That upward tick on the curve can burn people out, of course, so is a violation of the Agile sustainable-pace principle. When you adjust scope more often, and have small work increments/stories, the line tends to flatten out. Your situation may well be different, of course.

[@mikeparker6580]

@@AllenHolub Sorry for the (really) late reply. I was talking about the _scope_ line, not the _velocity_ line. I.e. some projects you end up finding lots of work right at the end. I was on one project where we were delivering simple stuff first, delivering early and often but in the end it was the really complex use cases of everything tied together that multiplied into an insane amount of work. I have no idea how we should have dealt with the fact that sometimes, towards the end of the project, you realise you are nowhere near the end of the project, as the scope line suddenly skyrockets and you start uncovering 2 weeks of new work every 1 week. The project in question was to design a system to merge changes from one database to another including schema changes and deletions of data that has been edited (sort of like a git merge with automatic conflict resolution). I guess we should have realised thats a very difficult thing to solve, but I guess we got ambitious and thought we were clever enough to do it. Senior management simply could not understand how we were getting further and further away from finishing as we approached our initial projected end date.

[@AllenHolub]

@@mikeparker6580 Delivering "the simple stuff first" is one problem. You need to sort the work by value to the customer, always working on the most valuable thing next. Developer convenience should be an irrelevance. It's rare that the most valuable work is also the simplest. It's normal, of course, for new work to emerge as you learn more about the problem, but as long as you're focusing on value, you'll have something worthwhile to ship if there's a hard deadline. If I were coming in as a consultant, I'd probably start there, but getting the work under control. I'd also look at your architecture. Agile architectures have to develop incrementally as the system grows. That's a learned skill, and your problems with the database implies that you don't have that. There's also an implication of a hard-core waterfall long-term plan rather than the dynamic planning that you need to do in an Agile system, so there's some work that needs doing on the business side as well.

[@mikeparker6580]

@@AllenHolub What about projects whereby the majority of the work is MVP? I.e. you dont have anything useful unless the majority of the work is done? For us this was the case - customers did not want migration software which only migrated half their database. It needed to be all or nothing. Our stories were often broken down into which data types we would write migration code for, and the customer didn't care which order they were done in, because there was no product until they were all done. Thats why we did the simpler data types first, to start building the architecture, try getting some simple test cases done, etc. To give a rough size - the project was initially 4 developers for 12 months. After 6 months it looked pretty much OK (6 months left). Then after 9 months it was clear we had at least another 9 months left. After 18 months i think it was probably another 18 months. I can't see any way we could have predicted that except by thinking really long and hard about all the various algorithms in some massive up front design, and even then theres no guarantee we would have spotted the complexity.

[@AllenHolub]

@@mikeparker6580 I haven't actually seen what you're doing, so I'm just shooting off at the mouth, here, so could be completely off the mark. An MVP is the smallest thing you can create that proves a hypothesis about marketability. In your case, the MVP would determine whether or not your customers were interested enough in a database migration to justify even starting the work. What business results would improve by migrating, for example. How would making that change provide more business value to your customers? How would it save them money or make their work easier or let them do something important that they can't currently do? If they're not screaming for it, I'd question whether you should have even started the work. Technical work of this sort is rarely justifiable. However, let's assume that you could justify the work. No work is predicable. An agile approach would involve constant reassessment. You plan dynamically, changing the plan daily based on what you observe, updating things like a CFD so that you can make projections. If those projections start trending in the wrong direction, you change the plan. That could involve everything from adding people to canning the project. To wait 6 months to change the plan was way too long. The plan should have changed much sooner. What you're describing is an up-front plan that didn't play out as expected. Up-front plans never play out as expected :-).

[@rkd80]

Had anyone done the story mapping method?

[@arnaudviguie]

Counting stories VS estimating roughly epics and their main stories. If you replace estimating by counting you need stories equivalent in size, else this does not work. How do you do that? Either with very experienced people both in their skills and in the topic so that they intuitively know how to break down stories into ones of similar effort, or being lucky that the type of work your teams works on is usually made of similar size items. In short, not giving a high level estimate to your main stories is not always working. Maybe the teams at Tesla autopilot did just count their number of stories before Musk said it would be ready by 2017? Now I understand the bad side of estimating, but I believe the options given here are throwing the baby with the bath's dirty water. Also, in my mind, estimating is linked to planning, and although plans are useless, planning is indispensable, and high level estimation helps the teams align on their understanding of the scope and true aim. I cannot recall the number of times when simply asking a team "ok, what are your acceptance criteria for this story?", or "what type of feedback would you look for from your users once it s done?", led to serious rethinking and realignment. I think pushing people, especially inexperienced teams, to not do estimates can be dangerous. NB: I like Allen and recommend often some of his videos to people, but sometimes it sounds a bit too black and white, and I tend to like nuances, especially as I work with not just software teams but also hardware, marketing, etc.

[@richie5um]

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.

[@praleadanut]

I like and support the idea of the presentation, although at 30:35 +Allen Holub 'cheats' and shows 3 vs. 5 sprints data with data changing only for the number of story points. (for the 5 sprints, the number of stories remain the same) He actually states that 'the number on the right is identical!'. Of course it's identical, because it's exactly the same charts/bars as in the previous slide :)

[@AllenHolub]

+Dani Pralea The data was the same after 5 sprints! I'll have to go look at the slides (I may have a cut-and-paste error), but the problem, if there is one, is in the slide, not the data.