Рет қаралды 188,791

Allen Holub

Allen Holub

Күн бұрын

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.

Пікірлер: 276
Healthy Software Developer
Healthy Software Developer 5 жыл бұрын
Fantastic presentation. One of the most valuable videos on KZhome 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!
Honk der Hase
Honk der Hase Жыл бұрын
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 :)
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 9 ай бұрын
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.
Center Field
Center Field Жыл бұрын
The "count the stories" approach might have worked well because the team was good at estimating equal-sized stories.
Twubbles 29
Twubbles 29 10 ай бұрын
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.
BladeTheWatcher 4 жыл бұрын
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-noor 3 жыл бұрын
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.
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 7 ай бұрын
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.
Programming Made EZ
Programming Made EZ 2 жыл бұрын
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.
Vikram Krishnan
Vikram Krishnan Жыл бұрын
So more akin to a Kanban?
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 7 ай бұрын
That sounds interesting, and my question is why you use Story points for this instead of just impediments?
Sellis Simoh
Sellis Simoh 2 жыл бұрын
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
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 9 ай бұрын
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...
TK Жыл бұрын
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
TK 10 ай бұрын
@Zealy exactly what I said would happen too, but the same po/pm would fight to get them lowered, which was insane
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 7 ай бұрын
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.
simple man
simple man 27 күн бұрын
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.
mateusz gepert
mateusz gepert 10 ай бұрын
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 😂
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 7 ай бұрын
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...
Mark Lindell
Mark Lindell 4 жыл бұрын
I soft deleted ~70% of our backlog 2 years ago and no one ever noticed. It was amazing!
Ric Morris
Ric Morris 4 жыл бұрын
Or they had already resigned themselves to none delivery
Ajay Bandi
Ajay Bandi 3 жыл бұрын
MR2 Spyder Journal
MR2 Spyder Journal 2 жыл бұрын
Shubhodaye Жыл бұрын
😀... @Mark Lindell, you still continue to do soft delete of backlogs?!
Kahn Жыл бұрын
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
Alexander Whillas
Alexander Whillas Жыл бұрын
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
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 7 ай бұрын
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...
Eli 3 ай бұрын
Coming from the perspective that as a team leader I had great success measuring velocity as a tool to estimate capacity at deadlines, From my experience velocity can be greatly improved by developers, the better quality work we do, the better the velocity will be (less tech debth, less bugs, code that is easier to maintain, etc.)
Alex Martinson
Alex Martinson 8 жыл бұрын
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.
Kahn Жыл бұрын
You mean you tried NOT to murder the boss.
Marcin Misztal
Marcin Misztal 9 ай бұрын
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 :)
Frank Harland
Frank Harland 5 жыл бұрын
Finally someone with a sensible story. Hats off.
Choe Elvis
Choe Elvis Жыл бұрын
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?
urban metal
urban metal 3 жыл бұрын
You deserve more subscribers. Especially CEOs. They need what you preach.
Tomas Kulhanek
Tomas Kulhanek 5 жыл бұрын
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.
Songs for my daughters
Songs for my daughters 3 жыл бұрын
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.
Ujjwal Prakash Sinha
Ujjwal Prakash Sinha 6 жыл бұрын
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.
Dave Nicholas
Dave Nicholas 6 жыл бұрын
I completely and utterly agree. The people against #NoEstimates gets bad estimates... but they get bad late or bad software.
Mark Sandy
Mark Sandy 4 жыл бұрын
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)
Christian Metzler
Christian Metzler 2 жыл бұрын
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!
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 9 ай бұрын
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.
Kevin Dietz
Kevin Dietz 2 жыл бұрын
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.
Raja Nagendra Kumar
Raja Nagendra Kumar 2 жыл бұрын
The best way to follow is to have quarterly goals, and always look for still gaps w.r.t to reaching the goal, if those gaps keep reducing faster enough, we are perfectly on a professional path.
Al B 🗽
Al B 🗽 3 жыл бұрын
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!
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 9 ай бұрын
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.
Ben Purcell
Ben Purcell 5 ай бұрын
I've done this myself and it works, but it works when you have mostly similar size, well understood stories
Pankaj Shet
Pankaj Shet 2 жыл бұрын
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'!
Pohjoisen vanhus
Pohjoisen vanhus 5 жыл бұрын
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...
Allen Holub
Allen Holub 5 жыл бұрын
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 :-)
Flavius Aspra
Flavius Aspra Жыл бұрын
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.
El Capitan
El Capitan Жыл бұрын
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.
Carlos Arcediano
Carlos Arcediano Жыл бұрын
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.
Vlad Predovic
Vlad Predovic 4 ай бұрын
A story should not be large. Break it down.
Simon Robins
Simon Robins Жыл бұрын
This is a fantastic talk thank you!
Gravekeeper 2 жыл бұрын
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.
Alexandra Bondareva
Alexandra Bondareva 4 жыл бұрын
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?
Mike Parker
Mike Parker 6 жыл бұрын
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.
Allen Holub
Allen Holub 6 жыл бұрын
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.
Mike Parker
Mike Parker 4 жыл бұрын
@Allen Holub 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.
Allen Holub
Allen Holub 4 жыл бұрын
@Mike Parker 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.
Mike Parker
Mike Parker 4 жыл бұрын
@Allen Holub 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.
Allen Holub
Allen Holub 4 жыл бұрын
@Mike Parker 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 :-).
szym 8 ай бұрын
Fantastic presentation. Very few comments for a great video like that.
Marcus Hammarberg
Marcus Hammarberg 7 жыл бұрын
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
Allen Holub
Allen Holub 7 жыл бұрын
+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!
Marcus Hammarberg
Marcus Hammarberg 7 жыл бұрын
+Allen Holub Thanks for the comment and just to restate; I liked the presentation - very thought-provoking. Thanks
hellbroth 5 жыл бұрын
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.
hellbroth 5 жыл бұрын
What a great presentation. I love how you are cutting through the bullshit, well done.
xewa 10 ай бұрын
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.
Fernando Basso
Fernando Basso Жыл бұрын
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
Jimi Wikman - The Holistic Consultant
Jimi Wikman - The Holistic Consultant 9 ай бұрын
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.
Spiros Karaplis
Spiros Karaplis 5 жыл бұрын
This dude really knows what he is talking about
Alex Mort
Alex Mort 6 жыл бұрын
Perfect. Start of a new project tomorrow - gonna try it out :) Thanks, Mr!
k3ys 4 жыл бұрын
Did it work?
Michael Stock
Michael Stock 4 жыл бұрын
Excellent talk, thanks for sharing!
Jimi Okikiolu
Jimi Okikiolu 2 жыл бұрын
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?
andi shaw
andi shaw 11 ай бұрын
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.
goliateros 2 жыл бұрын
From my experience: Estimation is most accurate when it takes more time then solving the ticket.
R.M. 2 жыл бұрын
Is that counterproductive? Ahhh! Sarcasm!! Good one!🥂
Kahn Жыл бұрын
My team lead said this once: I could finish the ticket now (during the backlog review meeting LOL).
TheChillBison 9 ай бұрын
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.
Rocky1138 5 жыл бұрын
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?
Allen Holub
Allen Holub 5 жыл бұрын
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 5 жыл бұрын
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?
Allen Holub
Allen Holub 5 жыл бұрын
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.
Anh Vu
Anh Vu Жыл бұрын
it's great, counting sliced works are sufficient for projection & minimize wastes with estimation
Felipe Cordoves
Felipe Cordoves 2 жыл бұрын
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
Ragunath Jawahar
Ragunath Jawahar Жыл бұрын
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.
9paradox 2 жыл бұрын
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.
Pankaj Shet
Pankaj Shet 2 жыл бұрын
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..!
Defeqel Жыл бұрын
"When are we done?" "We can release now if you are happy with the feature-set that is available"
9paradox Жыл бұрын
@Defeqel 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?
Defeqel Жыл бұрын
@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.
Pete Williams
Pete Williams 6 жыл бұрын
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
Scrum 6 жыл бұрын
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
hayderimran7 4 жыл бұрын
this is the most legit guy i have seen on agile...
kkrac78 6 жыл бұрын
+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?
Allen Holub
Allen Holub 6 жыл бұрын
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.
Momchil Brashnyanov
Momchil Brashnyanov Жыл бұрын
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).
Mario Rossi
Mario Rossi 4 жыл бұрын
I love this man.
7th CAV Trooper
7th CAV Trooper 4 жыл бұрын
I've been saying this since the 1990's and everyone mocks me. Now I can tell them Allen Holub agrees with me!
Allen Holub
Allen Holub 4 жыл бұрын
Or they can mock both of us :-)
7th CAV Trooper
7th CAV Trooper 4 жыл бұрын
@Allen Holub At least I'll finally be in good company. Loved your talk. Will take in more soon.
Kahn Жыл бұрын
You know the Fuck Agile websites, right? Mr. Holub said gave the middle finger to Agile without raising his hands.
David Bloyd
David Bloyd 3 жыл бұрын
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.”
camshaft30 2 жыл бұрын
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".
Arun Gopi
Arun Gopi 9 ай бұрын
Fibonacci is used other than normal sequence because the difference in number is well reflected in human mind for Fibonacci
Roman Poltavchenko
Roman Poltavchenko 10 ай бұрын
Wow, thank you! the most valuble video.
Dani Pralea
Dani Pralea 7 жыл бұрын
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 :)
Allen Holub
Allen Holub 7 жыл бұрын
+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.
Rob 26 күн бұрын
Never been in a place where the bosses, the risk takers, told me 'hey take your time, you delivery when you deliver'.
Matt Hoffman
Matt Hoffman Ай бұрын
I do agree that estimations are “guessing” but isn’t velocity a part of scrum and agile?
Kay Molkenthin
Kay Molkenthin 3 жыл бұрын
29:30 So you work three months without a plan to make a "projection" that says "2 crossing lines tell me" the project will be finished six months later. Based on the example, this means that you have to work a certain amount of time to balance out peaks in the projection. That sounds logical, but in practice it's unrealistic. Because for three months (or whatever time) NOONE knows when the project will be "projected" as finished. Uncertainty in time means uncertainty in costs (resources). And that's not what the client wants and that's certainly not what you want as a company. If you are unsure about the availability of your resources, then you cannot run a company. In my experience from over 25 years of project practice, this way of thinking is wishful thinking and has nothing to do with practice. When you calculate an assignment or take part in a tender, you have to estimate (calculate) your offer. And if you have committed yourself to an offer, then you have also committed yourself to a scope of services. There is no possibility to say, Ok then you just get less customer, because we made #noestimation. Planung without control is nonsense, control without planning is bullshit.
Allen Holub
Allen Holub 3 жыл бұрын
Virtually nothing that you've said is correct. You start collecting metrics immediately. They will settle to the point of being useful in a few weeks. You can start projecting immediately, and you modify those projections daily based on actual work performed. Planning in an Agile world, where requirements are in constant flux, must by dynamic. In that world, software projects are never "finished." The questions are, when can you start getting feedback by deploying, and how soon can you produce revenue, and when does it stop being cost effective to continue development. If you're working in an agile way with very frequent releases, the first two of those determinations happen rather quickly (weeks, not months). A #NoEstimates approach is an agile one. If you're not Agile (and it sounds like you're not), then the approach has little value. For example, your notions of "tender" and "commitment" are fundamentally waterfall thinking, based on contracts that codify that thinking, and of course, a #NoEstimates approach won't work in that context. You cannot work in an agile way under a waterfall contract---you contract has to describe the way you actually intend to work. If you can't educate your clients to accept Agile, then either abandon any hope of being Agile yourself, or find a different set of clients. You may have "no possibility" given your current client set, but there are many thousands of contractors working with many thousands of companies worldwide successfully using Agile approaches. "25 years of project practice" is of no relevance if your practices have not changed in 25 years. Agile is a radical departure.
Kay Molkenthin
Kay Molkenthin 3 жыл бұрын
@Allen Holub This is the conflict with reality. For example, if you offer solutions in Germany that are suitable for public administration or large companies, then these are not agile projects, because these are not agile organizations either. And the solution to "find suitable customers" is not a solution, but also wishful thinking. Do I accept 2 large projects for 20 million EUR or 10 small projects for 5 million EUR? That is what medium size companies have to deal with and then they have to deal with the consequences. We are not able to impose an agile organization on our customers. The description says "particular" which is misleading from my point of view, I would say "only" fits better.
Allen Holub
Allen Holub 3 жыл бұрын
@Kay Molkenthin Well, you're arguing that you can't be Agile in Europe. I know of many people who are doing just that (being Agile in Europe), so I have a hard time accepting your argument. However, if you're saying that you, personally, can't be agile because you, personally, can't find any clients who are willing to work that way, so be it. As I said, the approach doesn't work in a waterfall world.
Carl Erik Kopseng
Carl Erik Kopseng 2 жыл бұрын
@Allen Holub He does not actually say you cannot be agile in Europe. He says there are clients that are not agile. Especially the public sector is geared that way: fixed budgets and public tenders with quite rigid framing. This is quite universal in the entire hospital sector across Europe, for instance.
Defeqel Жыл бұрын
@Carl Erik Kopseng The public sector spends a year's worth of budget just to decide on a contract, so they can hardly take a "let's give these guys 3 months, and if they are not good enough, try this other company"-approach.
Paul Kienitz
Paul Kienitz 10 ай бұрын
#noestimates isn't a methodology, it's a labor movement.
Winux Worx
Winux Worx 2 жыл бұрын
Counting stories is not enough when your stories varies in complexities.
Defeqel Жыл бұрын
I'm guessing the stories average out pretty quickly. Especially if well defined.
George Kirkham
George Kirkham 9 ай бұрын
Really like this. Do you have an alternative that Big Corporates will accept? I need to know. :)
Allen Holub
Allen Holub 9 ай бұрын
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 😄
Sherwin Soriano
Sherwin Soriano 2 жыл бұрын
Even with forecasting, user stories are still used in the example. Isn't having user story points imply we are still estimating?
R.M. 2 жыл бұрын
That's what it is. We still playing wizards game here 🧙‍♂️🔮🧿
kdakan 4 жыл бұрын
Estimates do work if you work on them. No estimates, no deadlines means no client, no product from the start. You can always predict your future by observing your past. A very similar product built by the same team takes about half the time of the first attempt, there is statistics to prove this, experience in a similar domain and technology matters a lot. Not every task is R&D and open ended research. You can build a smaller scale proof of concept, you can do small up-front outside-in design to improve your your grasp and estimation. Keeping a prioritiesed todo list (user story mapping) is not enough to buy your clients and investors., you need more mature ways if you are a professional.
Allen Holub
Allen Holub 4 жыл бұрын
I don't think that you understand how an Agile approach works. You must have a product vision when you start. Frankly, I have never worked on a software project that was not effectively an R&D project. I don't think there is such a thing. You learn as you work. Many (most?) of the requirements that you gather up front turn out to be flawed (or just plain wrong). Estimates based on a faulty understanding are useless. This thinking is the basis of all Agile thinking, so if you don't buy it, you're effectively rejecting an Agile approach to software development. That's fine, but in this talk, I'm focused on Agile development.
kdakan 4 жыл бұрын
@Allen Holub I don't think what I am saying is contradicting agile, I learned about agile and lean and flat organizations from TQM, JIT production and prototype-based auto manufacturing industry, not from the agile manifesto. Agile is not a religion, it is what works in the proper context, it was not invented in the sowtware industry at all. If every product is an R&D project, you are right, but I am not working in that context. I value your proposition but I believe it is contextual. There are ways to improve estimation, counting number of user stories would not work if the user stories are too big, too small, or not even in size, what if the most prioritized stories are the simplest ones. I believe it all comes to some small up-front experimental outside-in design, and experience of the team and organization after all.
kdakan 4 жыл бұрын
@Allen Holub Another thing that would help is developers getting a few days of disciplined training on the business domain from key business experts, so that they can grasp things without getting lost in user stories and can see the forest for the trees.
Allen Holub
Allen Holub 4 жыл бұрын
@kdakan Agile is not a religion, but it is also not an ill defined pile of fuzzy concepts. It is not a synonym for "what works." Working on "improving estimates" is, to my mind, a complete waste of time, given that you can do business planning quite effectively without them. To me, time spent estimating is waste in the Lean sense. It does not contribute to the value stream in any way. To me "a few days of ... training" in the business domain isn't nearly enough.
kdakan 4 жыл бұрын
@Allen Holub Fine, the only principle that holds true in any context is the Pareto principle, 80 persent of value comes from 20 percent of the features, 80 percent of the bugs come from 20 percent of the code. Not every user story is created equal, not all tests provide equal value. Counting stories does not add value same way that code coverage does not tell if the software is not buggy.
Jason Knight
Jason Knight 7 жыл бұрын
I keep watching this and watching this video. All my managers should watch this video.
Mark Lindell
Mark Lindell 4 жыл бұрын
Abraham Serafino I would be curious to get a link to one of those videos.... ;-)
Rick Beacham
Rick Beacham 3 жыл бұрын
​@Mark Lindell For real..
vanivari 3 жыл бұрын
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.
Kimball Robinson
Kimball Robinson Ай бұрын
A few thoughts. First, he's self-contradictory in a way. He wants to get rid of estimates and replace them with projections. But a precondition is *similarly sized stories* which requires experience and ... estimation. (The estimation is comparative rather than numerical). Estimates and projections are really two sides of the same coin, and you can have just as much toxicity with projections as anything else. Which brings me to the second point (2) Management needs to focus on value in small iterations, and that's the real point that he (and agile since the 90s) is really getting at.
Luis Rueda
Luis Rueda 5 жыл бұрын
This man knows!
Edwin Wiancko
Edwin Wiancko 5 жыл бұрын
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.
Manish M
Manish M 10 ай бұрын
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.
Kamil Zatorski
Kamil Zatorski Жыл бұрын
Do you not assume in your proposal that all stories are issued right from the beginning of the project? It is also a waste, because some of the stories you create may turn out that you will not start them at all because the conditions/requirements will change.
Riccardo Corsini
Riccardo Corsini 3 ай бұрын
Really interesting approach
Kaustubh Deshpande
Kaustubh Deshpande 3 жыл бұрын
I was wondering, if a developer would have told Steve Jobs that I can't give you timeline to finish this, would Steve have listened to him?
Allen Holub
Allen Holub 3 жыл бұрын
Did you know Steve? I did (though not well). He was, sometimes, a tyrant, but he was well aware of the iterative nature of good design. He wouldn't have put up with slips in production schedules, but design is not production. You cannot be creative on a schedule. Software development is a creative pursuit. I'm sorry that you seem to be working in a shop that thinks that cracking the whip is essential.
Ghost Bond
Ghost Bond 2 жыл бұрын
Steve Jobs had a whole thing on pointing your devs in the right direction then getting out of their way - you'd never see Steve Jobs telling people to story point things. Also Steve Jobs said in an intetview that he admitted working for him during Apple's early days was the most stressful period in most of his employees lives, and they couldn't have kept up that pace for longer - most of those people left when it became to much. And he was paying them an enormous amount amount of money.
praetorxyn Жыл бұрын
Meanwhile in 2021 I still get asked how long things are going to take all the time >_>
Andre Rubin
Andre Rubin 6 жыл бұрын
I think you missed the main point of estimation. The main objective of story points and estimating is not to obfuscate time, but to get the dev team talking about what needs to be done in order to complete a story. If 4 devs sized the story 5, but John sized 13, he might know something that the others don't (for example, that particular feature will have to also provide a walkaround to a recently discovered system limitation). Then, during the sprint, if Jimmy picked up this task, he would have totally missed that walkaround provided they had not 'estimated', either delivering a buggy product or the wrong thing altogether. Estimates are not about estimation, it's about flushing out how the feature will be implemented.
Allen Holub
Allen Holub 6 жыл бұрын
I cover that in longer version of the talk (which I'm incorporating into my Agilty class on agilitry.com). The main issues are that (1) you can have that discussion without the points, (2) The discussion tends not to happen when the point values *agree*, but agreement is often hiding things that *need* to be discussed. That is, you may be agreeing about points but for completely different reasons. If you don't discuss those reasons because you have agreement, they'll you'll be in trouble down the line, and (3) when points are used for estimates, you tend to be focused on the wrong thing, on implementation details rather than big-picture value issues. It's better to focus on value. If something is valuable enough, you have no choice about implementing it. In that case, the estimate doesn't matter. What does matter is making sure that the story is implementable. In any event, if the main point of planning poker is to have the discussion, then why don't you just throw away the point values once the discussion is over? That will eliminate at least some of the common dysfunctions surrounding estimates (like the notion of "earning" points, or being "behind" if you don't "get credit" for the points, or "improving velocity.") None of that stuff is good!
Andre Rubin
Andre Rubin 6 жыл бұрын
Planning poker and estimation is just a tool to achieve that. There are several ways and mature teams probably could just get down to business. But I still think it's a great tool. And the act of estimating doesn't take much time at all, since you are having the conversation anyway.
Krause 5 жыл бұрын
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?
Damien Gallagher
Damien Gallagher 5 жыл бұрын
I had the exact same question.
Corbett Brasington
Corbett Brasington 4 жыл бұрын
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.
Benedek Nagy
Benedek Nagy 4 жыл бұрын
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.
eric moss
eric moss 2 жыл бұрын
I once had a manager who told me he could account for unknown unknowns.
R.M. 2 жыл бұрын
What a superpower. Thanos + his fully equipped gauntlet would be mad jealous
arnaud viguie
arnaud viguie 5 ай бұрын
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.
bapluda 6 жыл бұрын
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
The Black Hundreds
The Black Hundreds 3 жыл бұрын
To be fair, Bezos does look like some badly created villain.
Allen Holub
Allen Holub 3 жыл бұрын
I've thumbed up that one myself :-). I have no control over who the conference sponsors are, though.
R.M. 2 жыл бұрын
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.
Jim Deane
Jim Deane 2 жыл бұрын
@R.M. - 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.
Kol AI
Kol AI Ай бұрын
This summary was generated by Kol AI. - Estimation in software development is based on guesswork and is always wrong, leading to dysfunction and irrational schedules. - The real software product crisis is building code that doesn't do anything useful, and hitting estimates has no value if the program is wrong. - Problems with story points and velocity can lead to dysfunctional thinking and estimation. - Agile organizations should focus on projections instead of estimation, counting stories and using cumulative flow diagrams to make projections. - The use of story maps is suggested as a way to plan without estimates, with priority going down as you move down the map and time going from left to right.
Dave Penny
Dave Penny 2 жыл бұрын
It's unrealistic not to have an achievable plan based on our best estimates at every point in time. Business needs to adapt as our best estimates change over time. Without best estimates it's not possible to make feature trade off decisions.
Pankaj Shet
Pankaj Shet 2 жыл бұрын
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.
Dan Preda
Dan Preda 6 ай бұрын
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.
Channel Dad Bryon Lape
Channel Dad Bryon Lape 6 жыл бұрын
I'd love to subliminally play this in the ears of PMs while they slept.
Kahn Жыл бұрын
Thiện Khánh Nguyễn
Thiện Khánh Nguyễn 6 жыл бұрын
If the point is that no estimation at all- especially in Agile, how could we answer to the customer when and how much the product is?
Allen Holub
Allen Holub 6 жыл бұрын
I'm not sure what you mean by "product." Traditional work-for-hire contracts don't work very well. That is, if you have a very detailed specification, you could do a very-detailed analysis and come up with an estimate, but that approach rarely works. Since things always change (or go wrong), you have to set up an adversarial relationship with your customers (either you're padding to cover eventualities, which is to say that the customer is overpaying, or you have to eat the problems, which is to say that you're underpaid). So, you notion that you can accurately predict what it will cost to build software in advance is not correct. You can't. More to the point, since requirements always change during construction, you'll probably deliver a suboptimal product. There's no benefit in delivering the *wrong* thing on time and within budget. Finally, your customer is shouldering an enormous risk with this approach, given that they probably won't see working software until months (or years) after project inception. None of this is good. The #NoEstimates approach is different. You build incrementally. Consequently, your contracts have to be structured around working incrementally. I like two-week intervals. At the beginning of that two weeks, I sit down with my customer and we decide on a "story" to implement, and I deliver in (about) two weeks. I then get paid, and we move on to the next story. The customer can easily predict an overall budget based on the number of stories, and can predict release dates using the CFD that I demonstrate in the video. Working incrementally gives us the flexibility to build something truly useful; the *right* thing. Whether this is "agile" or not is debatable. Certainly, short cycles and incremental development are an important process of all the agile approaches that I know. However, "Agile" is way more than that. Though I wouldn't recommend it, you could work incrementally using a series of mini waterfalls, for example. What you can't do. Ever. Is accurately predict the cost of a software project up front, no matter what approach you use. The only exception is that a team is building a duplicate of a project that the same team built using the same technology for the same platform, and not that long ago. People who say that we just have learn to create more-accurate estimates, are delusional. We've been trying to do that without success for 60 years.
Thiện Khánh Nguyễn
Thiện Khánh Nguyễn 6 жыл бұрын
Thanks very much for your reply. I'm very interesting with the points that counting the number of stories. And, we make sure that building the right things from the beginning and giving the valuable things rather than wrong things on time and within budget, I agree with you. I meant that product is the final-product. I know that nobody look at documentation, and even programmer don't know that exists. However, from the customer perspective they want everything within a limited budget. For me, the problem is that most of the customers they don't know what they want to do at the first time, and they will tell us what they want until they see the product, another is we can just only estimate base on the experiences, if we come up with something new, we have no idea how to estimate that. But, the customer alway keep asking about how much and how long will it take in the OVERALL? You said that counting the number of stories is good enough for accurate estimation. Yes, it could be if all of the stories that we've done it before and all the team know how to do it. And one more question, what did you mean by top priority is building the most important thing first? How can we know that it's important? from customer point of view or from your assumption? Thank you again.
Allen Holub
Allen Holub 6 жыл бұрын
That's exactly why you want to work incrementally. It should take no more than a couple weeks to start getting software into your customer's hands, and you should continue to release every couple weeks. You should then incorporate their feedback into what you're doing. Yes, many customers are used to big up-front specifications, but at the same time, they hate having to wait a year before they see anything (for good reason). You have to negotiate your contracts to replace that big up-front specification with regular small releases and the ability to change what you're doing. I'd recommend supplementing my video with Vasco Duarte's "No Estimates" book (goo.gl/qlqElO).
Anton Spaans
Anton Spaans 6 ай бұрын
@Allen Holub Interesting discussion thread. And all are valid points! However, if a consulting agency is bidding on a project of a prospective client, with the aim to win that project, to get the foot in the door, how would the agency set the bid/pricing for this project without some form of estimation?
James Anderson
James Anderson 4 жыл бұрын
I have been saying this for years. Sad I only have one up-vote. great video.
A. EHER 4 жыл бұрын
How complex do you think it is to stop to use estimates? 🤔
nikotwenty 7 жыл бұрын
isn't cumulative flow diagram the same!e concept as a burn down chart?
Allen Holub
Allen Holub 7 жыл бұрын
+nikotwenty Not exactly. A burndown chart is typically used during a sprint to track the tasks that you'd perform during the sprint. I don't much like those because the set of tasks always change as you work, but the burndown chart will treat that as a negative, not as a trigger for a scope change. That is, a burndown is a tool to determine that we're "on schedule." The CFD is project-scope, not sprint scope. It's also tracking stories, not tasks. It's main purpose is to see when you need to adjust scope.
nikotwenty 7 жыл бұрын
+Allen Holub ok thanks. I thought burndowns were story based too. guess I'll have to look again at them
Allen Holub
Allen Holub 7 жыл бұрын
+nikotwenty I suppose you could use a burndown for your backlog, but there's not much point. Backlogs always grow. The problem is prioritizing the stories (and discarding the low-priority ones). A burndown won't help you with that.
Riccardo Audano
Riccardo Audano 6 жыл бұрын
I do like most of your points, but I think it's unfair to trash burn down charts as a meaningless and valueless waste of time, and then proceed to praise cumulative flow diagrams, when at heart, they are essentially the same things. (as way too often happens in "agile methodologies" and practices, where you have one thousand names for the same thing, just because you have one thousand chaps wanting to sell their "product"...) It' s pretty sad to see how the values of the agile manifesto have been corrupted into a means to sell "development methodologies products and experts" fighting to impose their conventions...it really reminds me of the "diagramming wars" at the the time of Waterfall Development and Documentation Fetish.. The same warts, just with different names.. I suggest you watch your own talk "The Death of Agile" :) and "Agile is Dead" by Dave Thomas ...and then rethink about the "righteousness" of cumulative flow diagram over burn down charts.. :) This being said, I absolutely love your "attitude"!
Allen Holub
Allen Holub 6 жыл бұрын
No. They're not the same at all. A burn-down chart is just telling you how much you need to do in the current iteration. They focus on tasks, not stories, and, in theory, tell you whether you're "on track." The worst thing about them is that they perpetuate the notion of a Sprint "commitment," a word that you won't find in the current Scrum Guide (which uses the word "projection"). If the burn-down rate changes, people treat it as a problem rather than as a normal result of working in an agile way. That is, you will learn as you implement, it's natural for new tasks to appear as a consequence. The Scrum Guide says that you should work with the PO to change scope at that point. Burn-down charts don't encourage that way of thinking.
jens bendig
jens bendig 8 ай бұрын
I say the same since 15 years or so. I seem not to be alone with that.
Tianyun Zhang
Tianyun Zhang 7 ай бұрын
I hate those refinement sessions where you spend an hour or so just on estimating story points
Jw9dneu7 11 ай бұрын
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?
BGivo 3 жыл бұрын
The "roll" of management..
Alan Lenarcic
Alan Lenarcic 2 күн бұрын
Why should a batter and a catcher and an umpire be working together? Arent they on different teams? Why should a catcher want to suppport or change whatever ritual the batter is trying to do? Shouldnt a catcher be trying to exploit weakness of the batter?
Hin Chan
Hin Chan Жыл бұрын
are we willing to be hired by 2 weeks basis and see how we work then extend another 2 weeks of our employment contract?
BGivo 3 жыл бұрын
Maybe he has a somewhat valid point, but this kind of utopian thinking doesn't really work in the real world. Good luck finding a client that will give you money without an estimate.
Allen Holub
Allen Holub 3 жыл бұрын
You can't work in an Agile way unless you have clients who are willing to work in an Agile way. I've found many of those. Too bad that you haven't. In general, the problem has to be solved by describing the way you work in great detail. Many clients, once they understand that you'll be delivering working software every few days, are more than happy to work in this way. It's not "utopian" at all, but it does involve real client-management work on your part.
BGivo 3 жыл бұрын
@Allen Holub Fair enough. Perhaps you've had a different experience. I was referring to my particular context in an agency working with pharma companies and banks. There is no way we can even have a seat at the table unless we are willing to present design docs and agree on an estimate before they give us a single dollar.
Allen Holub
Allen Holub 3 жыл бұрын
@BGivo Not sure about pharma per se, but I do know that there are medical-device companies (e.g. Medtronic), and pharma-related-clinical-data-management companies (e.g. Veeva) that happily work in an Agile way. It is possible.
Kaustubh Deshpande
Kaustubh Deshpande 3 жыл бұрын
very wrong baseball analogy here. A player in any game does some things to concentrate, not to lose focus eg the baseball batter, playing with strings of the racket in badmintion, tennis, tap the ball trice before the serve in tennis, in cricket its tapping the pitch with the bat. It has nothing to do with destructive rituals. In fact, it has been adviced to do so by coaches to bring the focus back in the game. These kind of comparisons are made only by the people who never played any game in their life.
R.M. 2 жыл бұрын
Success in Tech
Success in Tech 3 жыл бұрын
So we went from Time -> Story Points -> # of Stories. Cool.
R.M. 2 жыл бұрын
In real terms, how is # of stories any better? I wonder. 👀👀👀
José Gabriel Paz Sánchez
José Gabriel Paz Sánchez 3 жыл бұрын
We should not avoid estimations, they help us to decide the path we can take or the approach we follow. For example: We choose the approach 1 because it will give us the bigger business value in less time, we are estimating with the information we have, and the end of the sprint we will know if we were correct or we fail then we can adapt and try again. It is a waste if we are stuck analysis by paralysis and it does not help us to make decisions.
Houssem Zaier
Houssem Zaier 6 жыл бұрын
I have never gave a good estimation to my managers...
No estimates by Vasco Duarte
Рет қаралды
The death of Agile - Allen Holub
DevWeek Events
Рет қаралды 111 М.
Зубной бум: Мама vs Боль! 😬
Family Box
Рет қаралды 6 МЛН
Huggy Wuggy Vs Mommy long Legs в Squid Game : Ешь быстрее !
Фани Хани
Рет қаралды 3,5 МЛН
trang điểm sô cô la Chocolate Makeup Mukbang #shorts
DONA Việt Nam
Рет қаралды 66 МЛН
Хорватская тачка ▶️ Тесла #shorts
This is Хорошо
Рет қаралды 3,3 МЛН
Why Scaling Agile Doesn't Work • Jez Humble • GOTO 2015
GOTO Conferences
Рет қаралды 241 М.
How we can correct the mistakes made with Agile • Allen Holub
GOTO Conferences
Рет қаралды 59 М.
A Philosophy of Software Design | John Ousterhout | Talks at Google
Agile & Scrum Don't Work | Allen Holub In The Engineering Room Ep. 9
Continuous Delivery
Рет қаралды 80 М.
No Estimates? By Woody Zuill (@WoodyZuill) At Agile India 2017
How To Estimate User Stories? | #9
Vibhor Chandel
Рет қаралды 39 М.
YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)
The Death of Agile (Allen Holub)
Allen Holub
Рет қаралды 72 М.
How To Estimate Software Development Time
Continuous Delivery
Рет қаралды 144 М.
Hero Girl and Mean Duo At The Beach😂‼️ | JJaiPan #Shorts #tiktok
เจไจ๋แปน J Jai Pan
Рет қаралды 49 МЛН
Пранк Starbucks
Рет қаралды 4,3 МЛН
Ages 1 - 100 Fight For $500,000
Рет қаралды 110 МЛН
Super Max
Рет қаралды 10 МЛН
Changing a tire with nails 🤯😂
Supercar Blondie
Рет қаралды 6 МЛН