One of my pet peeves of fibonacci story point numbers is that they're not even linear. I can easily do 8 one story point stories in a day, but an 8 story point story will take me a a week (if not more). So summing them to calculate some sort of velocity doesn't make any sense, even if this velocity could've been used for something useful - which it can't. We're doing t-shirt sizes for epics, but because they need to fit into sprints they're always transformed to time anyway, which makes the t-shirt sizing step pointless. We're just doing it because ... agile! Not to mention that estimating epics in the first place is an exercise in futility. Needless to say, I hate estimation with all my heart, and this video was 🔥!
It's intentional to use non-linear sequence of numbers. You can use geometrical progression if you like, but then it would be too steep. The idea is, as Allen explained, that the more points, the harder to estimate correctly. We would have not accepted to sprint if the number >=13, and we would be required to split into multiple smaller stories.. Sometimes, we would end up with a smaller number, sometimes, we would end up with a much higher total number of stories to cover the original story that got split.
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.
Fantastic presentation. One of the most valuable videos on RUclips 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!
Many points I disagree with. And I'm not even a manager, but rather a dev. We, as a team, would use to defend us from overcommitting, and as well, to say hard stop when some eager dev would just nod and beat to his chest that he can still accept more work - "we'd be like, NOPE! 120 points is our cap, last time we did only 115!" So, it's if we have scrum in place. If you have kanban in place, I wholeheartedly agree with everything that Allen said. It's just it seems he speaks with scrum in mind. And if scrum is used to run how the team work, estimation is a must. Get rid of scrum, work in Kanban style, I'd be happy as Larry. We would switch to Kanban around New Year, with people leaving for vacation, and coming back, and etc, thus we would not have a good number how much we could accept for the sprint. Retrospectively, I can tell, that for some reason we would have achieved so much more - for some reason we would be so chill and relaxed without that sprint pressure, that we would work faster, and enjoy way more. I tried to push for it, but fell on deaf ears.
@@bajatoma if what you're saying is having no estimates in scrum is harder than in kanban, I'd agree. Inherent to scrum is this idea of "capacity planning". Which makes sense if you're truly expecting everyone to line up at the same time with their work done at the end. I've always considered scrum "agile with training wheels". Once you know how to get good requirements, test, and deploy in an iterative fashion; having everyone be done at the same time is of no value. It's better to eliminate queues and optimize for flowing output through the team faster - which kanban excels at. And at that point, estimates are a complete waste of time.
Any manager should be asked to estimate, how long it would take him to write a 500 pages book. If he asks what about, answer "we don't know yet", but let him estimate the pure work to write some words on a sheet of paper fivehundred times. Take this time for granted and tell him, what the story of the book should be about (a thriller) and the basic plot. And when he is mid-through writing the story, change the perpetrator... this should help him understand, what estimation for a developer is like :)
If the manager is a writer and have written dozens if not hundreds of books before, then that estimate should not be very difficult. Estimates are ALWAYS based on what the requirement was when given. Changing requirements ALWAYS require a new estimation. That is requirement management 101 after all... If you don't have enough information on what to actually build, then don't give estimation and ask for clarifications. It is the basis of requirement management after all, so if you have a requirement process this should never be an issue.
I think coding is much more complex than that. A better analogy would be write a 1,000 page book, but if you make a typo on any page it could cause your book to be rejected by the publisher. You also don't know what constitutes a typo, or even which grammar the publisher is using, because you are not the publisher.
@@jimiwikmanofficial Estimates are waste. Unless the requirement is something very basic and generic that was done probably at least a dozen times, any estimate is a guesstimate.
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.
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
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.
"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.
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
I think they don't even do this Scrum thing themselves (is either Amazon or Google) and for Intel I personally doubt they do any kind of Scrum ot Agile, since they're a hardware company and doesn't go well.
@@errrzarrr - it’s a shame though as The Mythical Man Month and Soul of a new machine illustrate. One about IBM System 360 and the other about a new processor. Both books deal with agile projects and small teams.
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...
The projection model built on counting stories depends on the assumption of a fully elaborated backlog where stories are all "small" (or "appropriately sized"). Now producing that also takes tons of work, and can be considered a waste as there are tons of changes in the backlog. I am not saying this is a bad idea - just stating that regardless of the method, getting projected or estimated dates will have a considerable cost associated with them, and with increasing desired precision the cost will also increase.
If you have 100 big and vague stories and you just start, then you take for example 5 first most important stories and work on "slicing" them to smaller ones. This way you don't waste time on working on all 100 stories to make them comparable size. So let's say that those 5 stories were worked on and became 20.. so you have 115 stories now, and you've done for example 5 small in the first iteration/sprint. You can make a projection out of that (5 to 115). Then you continue to work and make vague stories more specifig which changes the size of your backlog as you go and the prediction date changes as well. Doing the most important things first (which changes as well while we learn about the problem and business) you may actually finish the work earlier without even completing everything from the backlog. So it takes tons of work, but you do this work only when necessary to progress in the work. And based on this the projection updates. It's live. The assumption here is (as stated in the video) that the client invests small batches of money for each iteration and makes decisions based on constantly updating projections (for example by throwing out stories, changing priorities, stopping project or getting more people involved). [Customer collaboration over contract negotiation]. The problem with estimates is that the client/manager believes in them, so when you are near the deadline it's already too late to make game changing decisions, because you hold to your belief for way too long until it's too late. Projection based on counting stories shifts the focus to: what's the next most valuable story I want to be worked on to have something of value when I stop investing more. At least this is how I understand the talk. YMMV.
True. Estimations should be done on the level that makes sense from a collaboration and financial perspective. You always need some way to know if the value created is motivated by the cost and a prognosis on when it will be completed in case there are other things in the company depending on that development, or other development that might need to push that back or forward in time.
Estimation does work...for management. They play down the significance and validity of estimates when they want you to make them. And then treat them as real later on. And they know this. And we know it. Or should. This is one reason why people do startups; to get away from people who think they can control the creative and problem solving processes. To me, great teams want to create. They want to get into and stay in a flow state. They love collaborating when a problem needs solving. And they love doing their own thing when they know exactly what needs to be done. They love it when they can streamline things, execute fast and eliminate bugs. They love making a tool that can produce a lot of value with a little bit of user effort. They love it when a user arrives on a page for the very first time and says "Oh, I get it!" And when the user pushes a button and gets exactly what they expect as a result. So put them in a meeting. That'll put a stop to all that!
Estimations are always for management to make plans to coordinate efforts across the organization, as well as to keep track of costs for value creation. They are the ones that have to present why development teams should keep existing based on the value they create that always have to be higher than the salaries the companies pay for them. You can never get rid of that fact because every single developer work withing financial structures. If you make life more difficult for managers, you will not only risk your job, but you will undoubtedly see micromanage and get disturbed all the time by managers that NEED to know time vs cost at all times. That is their job.
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.
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 :)
This made me sad. It made me realize how great things could be, and how far away my current workplace is from that greatness. Amazing talk. If I ever get a say in how to run a project, I'll definitly put the idea of rebelling against estimates on the table
I hope you get the opportunity to be a Project Leader. It will be interesting how you would implement this, considering your number one responsibility as PL is finance and value creation withing the defined time. I would really like to see your first few steering meetings without a single estimate to make the prognosis against other initiatives...
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.
I would love to work at such organisation. I'm always amazed how much time we spend on grooming sessions about estimating things that in the end we even started doing 😂
What you are doing is helping the business side to spend their money wisely. Estimations will show if the investment in time and money spent will generate value that make the investment worth it. Considering that as a developer your job depends on the business making money, that should be a high priority...
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.
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.
And this assumes your backlog stories are evenly sized. Good luck counting stories when some are mere text changes and some are to implement new features. If you are to get roughly equally sized split stories, you have to work too, then why not save that time putting a higher or lower story point value on those instead? It gets the same result as he says.
@@tharindu79 Since I wrote my previous comment, I actually tried the story counting method and it worked well, surprisingly. It didn't matter that the stories are not equal in reality, as the sum of all the items in the backlog matters for understanding the project size. It also helped that we had a customer who was aligned on partial and continuous delivery. What was more surprising was that this way of "estimating" was closer to the actual effort than the estimate of the team following grooming.
@@Jedimaster36091 good god! i wish i could try this in my next sprint. But what about the prioritizations? Won't the client need the weights in order to take certain decision on what to build first?
@@Jedimaster36091 It's this "partial and continuous" delivery that seems to be the key. It's much easier to get a business commitment for 3 months work (and the associated risk that it might take 4, or even 6) than for a year (or several!) as long as there is a clear immediate benefit at the end of those 3-6 months. When you have over a year before you even *begin* to see a benefit, that's a much harder sell and invites the kind of nonsense that sparks videos like this one. This seems to be an argument for formalising 'skunkworks' into an orgs budget that would prototype things the org would like to see in future. At the end of a small project, the expected benefit is improved internal knowledge of the domain (including information to help management with future decisions pertaining to the domain), as well as a reference implementation for when it comes time to integrate with other components. Otherwise you get either: a) stagnation as no-one wants the large upfront cost and risk b) traditional estimate nonsense c) people treating enhancements like technical debt, essentially hiding the time they spend on it so no-one can tell them no. and I've seen all 3 in my current project.
@@Jedimaster36091 Thanks for responding to your own initial comment. Fantastic. How was the team doing? did you do that story counting unofficially while the team was doing its own stuff, following the old process?
For those Agile advocates claiming estimations are waste, I have a question. Are you comfortable to sign contract for building your house with a construction company, that will tell you no price and time estimates? How do you choose from three different offers, none of them provided price neither schedule. When you will be doing next reconstruction or will be relocating, do not ask for price neither date. The second interesting thought is to get out middle management, as they are only asking for estimates and chasing people until they burn out. So people will hire themselves, onboard themselves, figure how they want to work themselves, decide their performance and compensation themselves, thousands of people in company will decide their tools and strategy themselves, and take everyone will automatically take legal responsibility for compliance and if audit comes the auditors will speak with hundreds of people at the same time. As much as I like certain ideas in this talk and feel inspired, some seems really stretched to a fantasy land and quite risky if implemented. All well known organizations which implemented flat model failed so far and returned back to management lines. But I am curious to hear about success stories if you know about organizations which implemented these ideas and how they worked out after several years.
As well, saying that one can not improve on estimating is a false claim. Few will still get overestimated, most will still be underestimated , but all that with lower margins of error. "I've done big form before, 13 points, usually layout issues, need to add more work towards responsive layout, more effort validating). Oh, it's a 3 field form, 5 points then. Still needs to be tested and all, a bit more than fixing something simple (2-3 points), or updating a label (1 point)" Not that hard, isn't it?
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.
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.
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.
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.
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'!
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.
@@kspfan001 So, we have a bad link on a page. To fix it, it's 15 mins job (change, test commit... nothing is less than 15 minutes). The value to the business - well, the frigging web page doesn't work, users can't login. So, what is the value for the client? Huge. So tell me, how many story points?
I completely agree with every single word spoken in this talk. I myself have been increasingly skeptical and critical about estimates from many years now. After reading Thinking: Fast and Slow and The Black Swan, it is clear that estimates and predictions simply do no not work. Simple as that. There much evidence in the scientific community in form of research and observation of empirical facts that they do not work. I won't go into the details here because entire books have been written on this topic, but the simple idea is that we don't know about the future and how the countless variables change during a period of time. If estimates or predictions work only some times, it is random chance. We could as well just toss a coin to decide on how long something will take to complete or how much effort and resources it will require. As for the hurt story points and estimates cause for teams and projects, I can tell many tales of people closing incomplete cards in their ticketing systems just to meet a sprint deadline, merging broken, untested, subpar code, pretending that the tasks were completed within the allotted time, then creating further cards to do further work. Or, people feeling destroyed because sprint after sprint some cards are always spilled to the next sprint, cause bosses graphs to look bad, and endless meetings to discuss "how to prevent this to happen in the future", just to have it happen again in the next sprint. Story points and sprint deadlines are a good way to implement means on how to destroy team moral, bore the hell out of people, and make people lose the sense of meaning by forcing them to do things they know from experience don't work and is a waste of time, life and countless hours of work. But for people who want to pay programmers less [1], it is a good tool. 1. www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html
The idea that you always work with unknowns does not make any sense. It is true that you can not predict the future, which is why unknowns are always a part of the estimations as additional time. If you can't hit a 90% accuracy with your estimates, then you are either inexperienced, so you don't know how long things take for real, or you don't have enough time to properly evaluate and plan for what needs to be done. Not pushing back on rushed projects is always on the developer, and you should always write technical debt when code is not of the correct quality due to financial decisions. Providing realistic estimates eliminate this problem almost completely, but it requires you to actually know how to estimate and stop trying to make happy guestimates.
"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." Ha! couldn't agree more on that. But the issue is not so much in estimation, but rather in committing stories for a sprint. Kanban anyone?
I liked this presentation at first. Mr Holub gives a great and very passionate presentation. I like that. But really this is about #AntiEstimates (a tag that doesn't exists) and not about #NoEstimates. The latter is about exploring alternatives and doesn't say "Don't use estimates", but rather "Use estimates if you cant find something that is better; here's a few things we've tried". I think there's a difference. Great presentation - thanks
+Marcus Hammarberg: I suppose I am #AntiEstimates :-), though of course you could cast the projection techniques I discuss as a kind of estimate. You're absolutely right that #NoEstimates is more about having the conversation than coming up with a "solution," however. I see this talk as a part of that conversation. Being a practical-minded guy, I've layed out my solution, but it's certainly not the only approach!
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.
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.
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.”
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.
Interesting concept, he covered one issue with the perspective which is project feasibility but in my experience, what the business often need to know cost. Can we afford this project? Do we need to re-budget our business priorities? Do we need to hire more engineers and so on. Developer may be engineers but also service providers like lawyers and lawyers define their costs as time. The presenter explained how we can ignore time estimates, but what about the real issue cost?
You can't predict that and you should stop, that's the whole point. It will cost exactly what it costs to develop and guessing that upfront is always going to fail. You missed the point.
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).
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?
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.
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
This just reminds me of what Eric Brechner says in his talks about Kanban. Basically what you do in the model he teaches is break things up to chunks of roughly the same size, do your best to maximize flow, measure how many get done in the measured period of time and what falls in your lap is a rough projection. Yes, obviously the process of breaking things up into pieces of roughly the same size is estimation but to me it sounds somewhat doable. So if the stories are roughly the same size...
Definitely doable :-). At least I've been doing it for a while and it works great. Frankly, narrowing all your stories down works even if you still insist on estimating. I coach Scrum teams to do it, too. Not only is it much easier to gauge the work, but breaking up a big story into small ones uncovers all sorts of low-value, unnecessary work (which you then don't have to do!). I just came across a set of great planning-poker cards (estimation.lunarlogic.io/). There are only three cards, labeled: 1, NFC (No...Clue), and TFB (Too...Big). Bought several sets to hand out to Scrum teams :-)
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.
I think that story points have a great value, but not for forecasts. Namely: during planning poker, when all devs reveal their numbers, a discussion is triggered with the outliers. This makes for knowledge sharing.
but then the method is somewhat of a lie: people are told that story points measure something meaningful and it's all too easy for managers to interpret them as such regardless of the side effect that performing the task invokes discussion. indeed simply breaking down tasks as a group without resort to story points will be just as fruitful for one will notice where there is not enough information to reliably predict anything. the devil is always in the details.
@@errrzarrr same poop in a different hand, but you are "saving" on discussing whether the story needs to be broken down or not, because you didn't assign points to the story. Thus, sprints are going to be even crazier!
"Sprints" are the opposite of working in a steady pace. Did you ever see a runner doing one sprint after another, to run a marathon? You won't because it is nonsensical. But that is what sc(r)um does teach us!
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
This is great, except I didn't get a very clear answer to how to answer the questions: 1) When do you think you can have this done by? 2) We'd like to launch this year, do you think it's possible? How do we respond to managers who ask that?
Rocky, One of the problems is that's not an agile way of thinking about things. When presented with a time box (anything from a sprint to a year), the question to ask is "how much value can we provide in that time period," and of course, you learn as you work, so the things you'll be working on change. Even the Scrum Guide says that you should work that way. Your first question presupposes that you can entirely define a project up front. An agile approach says: lets build the smallest, most minimal thing we can get away with first, then based on actual feedback from actual customers, we can incrementally expand it. So, you get a set of stories, narrow them down to a day or two, and then work on them in order of value. "This," then is the next story. You'll be done with it in a couple days. Re your second question, that's the point of doing dynamic planning using a cumulative-flow diagram. It's making a projection based on actual measured progress and the size of the backlog, and not only answers your question directly, it gives you options if you don't like the answer. If the projected date is too far into the future, you can adjust scope and see the impact on the diagram. If your managers have fixed both scope and time, and they're not willing to add teams, that's a classic death-march, iron-triangle situation. That's just bad management performed by people who don't understand the fundamentals of business, and there's no solution to that particular problem :-). In agile projects, scope changes constantly. That's what agile is about, accommodating changing scope.
Thanks so much for your reply. I will take your advice to heart. I do have an unrelated question: is it possible to take the number of the stories completed against the amount in the backlog per the last three sprints from one project and apply it to a different project from another customer but the same team? Or must we always start out not knowing then, once we have 3-5 sprints done, we can project the rest of the timeline?
Well, your average number of stories completed per week will probably transfer, assuming that you're not changing technology or team composition. The main thing is that, to transfer the metric, you need consistency. On the plus side, I've found that the average "settles" pretty quickly, so if you get it wrong at first, the number will adjust within a few weeks.
@@AllenHolub If you had mentioned Kanban at any given point, I could buy that. Meanwhile, as a dev, who figure out how to use estimation to my own advantage, i.e. "look, it's 120 points, and we are not accepting more story points, we draw a line here". This won't work with a number of stories, you would need to discuss in detail what each story entails, to make sure we would not overcommit to the sprint, and maybe break down into more stories when accepting work to sprint, and the only thing you would be saving at this point is writing down a number. So, I wholeheartedly disagree that we should stop estimation in scrum setup. In Kanban, sure thing - no more than 5 active stories on the board. I'm about to pull one. let's have a quick chat.. Actually, most productive time I have experienced was when we ran in Kanban style. Was awesome, motivation through the roof.
Allen, I love your talks and wished there were more people in my company who have seen it. However I have one question regarding projections and the size of the backlog. If you say that probably 70% of the backlog could be deleted as we don't know yet if the stories are correct at all, how can I then do a projection? In theory the top 10 items are the ones where a projection might be useful, but then we're talking about probably one month of work, but not the whole project. Would be happy to hear your thoughts!
This only happen if you mix strategic and operational items in one backlog. If you understand the requirement process then you know that only actually decided requirements end up in an operational backlog and that backlog is reviewed every week, or at least every sprint, before you put things into the next iteration. Only if you don't have a proper requirement process will you have backlog stuffing, and even the team should remove things unless it is likely to be included in the next couple of sprints. The business need should be recorded elsewhere anyway, as that is not a requirement.
The correct answer to estimates is always "ten years". Will it really take ten years? Of course not. But if take longer than estimated, this is always a huge problem. It's never a problem if you are done early. So with an estimate of ten years, you will always be done early. See, there is a fundamental truth about all developing processes: You can either define the end of project by a feature set, then the project is done when the feature set has been reached but it is unknown how long that will take. Or you can define the end of a project by a time frame, then the project will end after a given amount of time but it is unknown what feature set you will get up to that time. But what you cannot do is defining both, feature set and time frame, as that will almost never work, that's only wishful thinking and in the end either condition won't be met. I call this the Heisenberg Principle of Development. So make up your mind what is more important to you, when the project is done or what feature set it will have and then go along with it. As the video says, if you are unsure, set smaller goals. Go with a small feature set and see how long that takes or go with a short time frame and see what you get, then adjust your future decisions accordingly.
I find the idea intriguing, but I see several significant issues with it: The backlog projection graph presented seems suitable for projects with a defined start and end point. This typically applies to projects ordered by a customer, where there is an agreement to deliver a finished product. In such cases, projecting the end date is crucial. However, many software projects are ongoing with regular releases. How can you project a subset of features or stories using this method? Building on the first point, managers often require estimates for specific epics, but this technique is a statistical tool that views the project as a whole. Using this graph, it is difficult to project meaningful information for a specific epic or story.
No doubt that the talk and the presentation was great. I really liked this #NoEstimates, but i still feel it is incomplete. It is like we are only discussing the problems in different ways, models and techniques, in every talk and articles over and over again (lol, i am doing the same rn). Those projecting techniques are good too, but when the client asks you 'by when are we up and running', and i guess we would reply them saying 'we will let you know when we are done, when we are done'. May be i am naive, just started as a junior developer. I believe client will not wait unless we provide them with all the dimensions and time being one of them. If i misunderstood something please let me know, like to learn and grow.
Why are the Managers there? Managers should be able to manage clients and not try to manage employees...! If you look in google maps, even it is not able to predict the right amount of traffic comming on the way. It just shows the current status on the map..! If anything changes the predictions too change..!
@@defeqel6537 hi thanks for sharing that. The question asked "when are we done", seems like it was asked after some development was made. But what if it was asked in the start?
@@9paradox The honest answer is "we don't know", but I realize many customers don't like this answer. The presenter mentions in other comments the need to also educate clients on agile practices.
If you play the video from 24:30, Allen discusses how to solve that problem. Given the current state of the backlog, and the current RATE of stories being implemented, you can reliably tell the customer when the product will release. You then have a few choices: a - kill the project; b - reduce the backlog; c - add more resources to change the velocity of the story implementation; or d - accept the date. The point at which the backlog line and the story implementation line intersect is essentially your date of completion.
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.
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 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.
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.
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?
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 😄
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)
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?
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
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.
I love this talk, but it relies, that the stories are written properly and with all requirements to count them, and in my point of view this is the real problem(know what they really want); new requirements are popping up after the program is implemented as defined. Due to a lack of knowledge between the business and the dev team. I think that this is the biggest problem (btw. I work in an env. where the business does have no clue about the effort of rewriting a whole workflow 😅)
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?
You don't need ALL the stories. All you need is the rate of change of added stories and consumed stories (do not log defects as stories...more on this later). If it helps, you can treat the backlog as candidate stories...until you associate them to a release. The planning that you saw on the screen is around a release, with a fixed number of epics (don't change the epics of a release if you can help it. This will simplify your scope and also help prevent your team from getting "whipped by WIP"). The accuracy of "When you will end" will get better and better the more sprints you do, but you need at LEAST 3 to have some sanity and confidence that your 2 rate of change and where they intersect are "good enough". Couple tips here: #1 do NOT log defects as stories they will confuse your backlog and you. When a defect is discovered (lets say through exploratory testing as hopefully you have automated TDD, the defect is validated from your product owner or the team that is actually a defect in the scope of that story....and then you fix it....immediately. Defects take the highest priority, the team stops what they are doing and you fix it. #2 Not having defects in your backlog will provide better data for your rates of change from stories. #3 To account for "time to handle defects" just reserve %20 of your teams capacity for defects in sprint planning. So if your team can typically only handle completing 5 stories in a sprint....cool, they only commit to 4 stories so they can predictably take care of defects.
I also wonder about the same thing and unfortunately I cannot answer it, but I want to note: if you are not sure you can count the number of stories, there is surely no point at all in estimating points/time for them.
I take story over functional requirements any day. I heard way too many of "Oh, I haven't thought about that" way too often when people come with functional requirements. The same might happen with story needs to be discussed, and groomed, and how is implemented is discussed and narrowed down. Often during those discussions when we would observe innovations coming from different people on the team . re: OCD: BS argument. Retrospective takes care of this. Scrum relies on self-managing teams. During retrospectives, we look back, see what worked, what didn't, and we agree on improving how things work, by adjusting the process. Bottom stories, ie wild fantasies: those are epics. big chunks that are there for visibility of how far we yet need to go to the finish. Normally, they are not fantasies, since these are pretty generic. Funny thing, what he talks around @21:50 is how scrum suppose to work, and what scrum is trying to address. As well, he does come across like a person who has never done product feasibility study from a business perspective. You do need to have some idea on how long before the product can be shipped, how many devs you'll need to implement, etc, thus estimation. "Counting stories is enough": Again, epic vs story. as well, having points in stories helps to not overcommit, especially when you have stories broken down, and some stories with higher number because they do not make sense to break down even further, but it's still going to take longer or is more complex (ie, breaking down would be true waste) Of course, if there would be no committing for sprint, then it's not an issue from this perspective, which I would love to see being gone - I hate committing to the sprint with passion.
how will you know when to stop accepting stories to the sprint? so, you will end up discussing on what the task entails, thus still pretty much doing exactly same work as estimating, but you would just save 1 second in writing down the number. Yay.. a win! /s
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.
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?
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.
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)?
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.
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.
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 :)
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.
I soft deleted ~70% of our backlog 2 years ago and no one ever noticed. It was amazing!
Or they had already resigned themselves to none delivery
hahahaha
Lol
😀...
@Mark Lindell, you still continue to do soft delete of backlogs?!
You silently removed items in backlog - they didn't notice.
They silently resigned - you didn't notice either.
Fair game I bet :D :D :D
One of my pet peeves of fibonacci story point numbers is that they're not even linear. I can easily do 8 one story point stories in a day, but an 8 story point story will take me a a week (if not more). So summing them to calculate some sort of velocity doesn't make any sense, even if this velocity could've been used for something useful - which it can't.
We're doing t-shirt sizes for epics, but because they need to fit into sprints they're always transformed to time anyway, which makes the t-shirt sizing step pointless. We're just doing it because ... agile! Not to mention that estimating epics in the first place is an exercise in futility.
Needless to say, I hate estimation with all my heart, and this video was 🔥!
It's intentional to use non-linear sequence of numbers. You can use geometrical progression if you like, but then it would be too steep. The idea is, as Allen explained, that the more points, the harder to estimate correctly. We would have not accepted to sprint if the number >=13, and we would be required to split into multiple smaller stories.. Sometimes, we would end up with a smaller number, sometimes, we would end up with a much higher total number of stories to cover the original story that got split.
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.
Fantastic presentation.
One of the most valuable videos on RUclips about software development IMHO.
As Allen says at the end (and I so agree with):
It’s up to developers to get this happening on our projects - management’s not going to understand the dangers of estimating until WE educate them!
Completely agree - but it is a VERY hard sell... on the surface, it sounds so easy, so simple and valuable to estimate...
Many points I disagree with. And I'm not even a manager, but rather a dev. We, as a team, would use to defend us from overcommitting, and as well, to say hard stop when some eager dev would just nod and beat to his chest that he can still accept more work - "we'd be like, NOPE! 120 points is our cap, last time we did only 115!"
So, it's if we have scrum in place. If you have kanban in place, I wholeheartedly agree with everything that Allen said. It's just it seems he speaks with scrum in mind. And if scrum is used to run how the team work, estimation is a must. Get rid of scrum, work in Kanban style, I'd be happy as Larry. We would switch to Kanban around New Year, with people leaving for vacation, and coming back, and etc, thus we would not have a good number how much we could accept for the sprint. Retrospectively, I can tell, that for some reason we would have achieved so much more - for some reason we would be so chill and relaxed without that sprint pressure, that we would work faster, and enjoy way more.
I tried to push for it, but fell on deaf ears.
@@bajatoma if what you're saying is having no estimates in scrum is harder than in kanban, I'd agree. Inherent to scrum is this idea of "capacity planning". Which makes sense if you're truly expecting everyone to line up at the same time with their work done at the end. I've always considered scrum "agile with training wheels". Once you know how to get good requirements, test, and deploy in an iterative fashion; having everyone be done at the same time is of no value. It's better to eliminate queues and optimize for flowing output through the team faster - which kanban excels at. And at that point, estimates are a complete waste of time.
Any manager should be asked to estimate, how long it would take him to write a 500 pages book. If he asks what about, answer "we don't know yet", but let him estimate the pure work to write some words on a sheet of paper fivehundred times. Take this time for granted and tell him, what the story of the book should be about (a thriller) and the basic plot. And when he is mid-through writing the story, change the perpetrator... this should help him understand, what estimation for a developer is like :)
If the manager is a writer and have written dozens if not hundreds of books before, then that estimate should not be very difficult. Estimates are ALWAYS based on what the requirement was when given. Changing requirements ALWAYS require a new estimation. That is requirement management 101 after all...
If you don't have enough information on what to actually build, then don't give estimation and ask for clarifications. It is the basis of requirement management after all, so if you have a requirement process this should never be an issue.
I've used an example like this but with making an album or film.
Even if a writer has written dozens of books, he/she could still fall into something called a writer's block. So, this is a realistic example.
I think coding is much more complex than that. A better analogy would be write a 1,000 page book, but if you make a typo on any page it could cause your book to be rejected by the publisher. You also don't know what constitutes a typo, or even which grammar the publisher is using, because you are not the publisher.
@@jimiwikmanofficial Estimates are waste. Unless the requirement is something very basic and generic that was done probably at least a dozen times, any estimate is a guesstimate.
I'd love to subliminally play this in the ears of PMs while they slept.
Inception!
I keep watching this and watching this video. All my managers should watch this video.
@Abraham Serafino I would be curious to get a link to one of those videos.... ;-)
@@MarkLindell For real..
The whole agile approach as discussed in this talk is build on the idea that the team is highly invested and pushes itself. In reality, there is a ton of boring projects out there staffed with left-over developers and graduates and if you let those people alone, you will have nothing after 2 years. Not everybody has the capabilities to be a Navy SEAL. If you work in a really large company with 10,000 or 100,000 of developers (e.g. in large offshore-centers), a very large amount of them is barely able to carry their own wight. I bet, many projects out there could remove at least 20% developers and the project would not suffer a bit.
Finally someone with a sensible story. Hats off.
This is sooo spot on! I worked with a team a couple of years ago where the project managers were always wanting to 'bag the points' and the team were told that there velocity had to increase every sprint! Total bollocks and resulted in quality dropped and people leaving
@@zealy1369 exactly what I said would happen too, but the same po/pm would fight to get them lowered, which was insane
Bad managers are common. That is why they are called managers and not leaders. Their job is to be overseer and their worth is based on the value they produce and often they use the whip to get it and not the carrot.
"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.
The ironic of this speech is that in the background is the logo of amazon, a company known for making their workers work long hours to achieve deadlines
To be fair, Bezos does look like some badly created villain.
I've thumbed up that one myself :-). I have no control over who the conference sponsors are, though.
I think they don't even do this Scrum thing themselves (is either Amazon or Google) and for Intel I personally doubt they do any kind of Scrum ot Agile, since they're a hardware company and doesn't go well.
@@errrzarrr - it’s a shame though as The Mythical Man Month and Soul of a new machine illustrate. One about IBM System 360 and the other about a new processor. Both books deal with agile projects and small teams.
The first video that I found about no estimates that answer how to plan for on time release. Thank you a lot.
I hate those refinement sessions where you spend an hour or so just on estimating story points
This is so spot-on, particularly about the role of managers, how most are not needed and those that are needed are a support role for the workers
You would be surprised to know the crap managers deal with on a daily basis :) Especially middle managers have the worst position in the whole company...
I've been saying this since the 1990's and everyone mocks me. Now I can tell them Allen Holub agrees with me!
Or they can mock both of us :-)
@@AllenHolub At least I'll finally be in good company. Loved your talk. Will take in more soon.
You know the Fuck Agile websites, right? Mr. Holub said gave the middle finger to Agile without raising his hands.
The projection model built on counting stories depends on the assumption of a fully elaborated backlog where stories are all "small" (or "appropriately sized"). Now producing that also takes tons of work, and can be considered a waste as there are tons of changes in the backlog. I am not saying this is a bad idea - just stating that regardless of the method, getting projected or estimated dates will have a considerable cost associated with them, and with increasing desired precision the cost will also increase.
If you have 100 big and vague stories and you just start, then you take for example 5 first most important stories and work on "slicing" them to smaller ones. This way you don't waste time on working on all 100 stories to make them comparable size. So let's say that those 5 stories were worked on and became 20.. so you have 115 stories now, and you've done for example 5 small in the first iteration/sprint. You can make a projection out of that (5 to 115). Then you continue to work and make vague stories more specifig which changes the size of your backlog as you go and the prediction date changes as well. Doing the most important things first (which changes as well while we learn about the problem and business) you may actually finish the work earlier without even completing everything from the backlog.
So it takes tons of work, but you do this work only when necessary to progress in the work. And based on this the projection updates. It's live.
The assumption here is (as stated in the video) that the client invests small batches of money for each iteration and makes decisions based on constantly updating projections (for example by throwing out stories, changing priorities, stopping project or getting more people involved). [Customer collaboration over contract negotiation].
The problem with estimates is that the client/manager believes in them, so when you are near the deadline it's already too late to make game changing decisions, because you hold to your belief for way too long until it's too late.
Projection based on counting stories shifts the focus to: what's the next most valuable story I want to be worked on to have something of value when I stop investing more.
At least this is how I understand the talk. YMMV.
True. Estimations should be done on the level that makes sense from a collaboration and financial perspective. You always need some way to know if the value created is motivated by the cost and a prognosis on when it will be completed in case there are other things in the company depending on that development, or other development that might need to push that back or forward in time.
you also take into account the growth of the backlog in your projection, it still holds
Estimation does work...for management. They play down the significance and validity of estimates when they want you to make them. And then treat them as real later on. And they know this. And we know it. Or should.
This is one reason why people do startups; to get away from people who think they can control the creative and problem solving processes.
To me, great teams want to create. They want to get into and stay in a flow state. They love collaborating when a problem needs solving. And they love doing their own thing when they know exactly what needs to be done.
They love it when they can streamline things, execute fast and eliminate bugs. They love making a tool that can produce a lot of value with a little bit of user effort.
They love it when a user arrives on a page for the very first time and says "Oh, I get it!" And when the user pushes a button and gets exactly what they expect as a result.
So put them in a meeting. That'll put a stop to all that!
Estimations are always for management to make plans to coordinate efforts across the organization, as well as to keep track of costs for value creation. They are the ones that have to present why development teams should keep existing based on the value they create that always have to be higher than the salaries the companies pay for them.
You can never get rid of that fact because every single developer work withing financial structures.
If you make life more difficult for managers, you will not only risk your job, but you will undoubtedly see micromanage and get disturbed all the time by managers that NEED to know time vs cost at all times. That is their job.
Thank you for this video. It feels much better after watching it. It showed me that I was not wrong. God knows how many times I have tried to hit my boss when he forced me to come up with estimates.
You mean you tried NOT to murder the boss.
Just because you've found a public speaker that is one the same page as you, doesn't automatically make you right :D You can literally do that with any thesis :)
this is the most legit guy i have seen on agile...
This made me sad. It made me realize how great things could be, and how far away my current workplace is from that greatness. Amazing talk. If I ever get a say in how to run a project, I'll definitly put the idea of rebelling against estimates on the table
I hope you get the opportunity to be a Project Leader. It will be interesting how you would implement this, considering your number one responsibility as PL is finance and value creation withing the defined time. I would really like to see your first few steering meetings without a single estimate to make the prognosis against other initiatives...
I experienced several sorts of managers. One sort gives me support to do my work and taking any obstacles from me. The second one use estimates, numbers and metrics to measure our performance and punish us on not meeting them. I also used estimates to give deadlines. This keynote gives me clue what I have been feeling subconsciously for longer time.
You give good examples - the takeaway is that Agile won't ever fix a bad manager. Not doing Agile, ALSO won't fix a bad manager.
You deserve more subscribers. Especially CEOs. They need what you preach.
I would love to work at such organisation. I'm always amazed how much time we spend on grooming sessions about estimating things that in the end we even started doing 😂
What you are doing is helping the business side to spend their money wisely. Estimations will show if the investment in time and money spent will generate value that make the investment worth it. Considering that as a developer your job depends on the business making money, that should be a high priority...
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.
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.
And this assumes your backlog stories are evenly sized. Good luck counting stories when some are mere text changes and some are to implement new features. If you are to get roughly equally sized split stories, you have to work too, then why not save that time putting a higher or lower story point value on those instead? It gets the same result as he says.
@@tharindu79 Since I wrote my previous comment, I actually tried the story counting method and it worked well, surprisingly. It didn't matter that the stories are not equal in reality, as the sum of all the items in the backlog matters for understanding the project size. It also helped that we had a customer who was aligned on partial and continuous delivery. What was more surprising was that this way of "estimating" was closer to the actual effort than the estimate of the team following grooming.
@@Jedimaster36091 good god! i wish i could try this in my next sprint. But what about the prioritizations? Won't the client need the weights in order to take certain decision on what to build first?
@@Jedimaster36091 It's this "partial and continuous" delivery that seems to be the key. It's much easier to get a business commitment for 3 months work (and the associated risk that it might take 4, or even 6) than for a year (or several!) as long as there is a clear immediate benefit at the end of those 3-6 months. When you have over a year before you even *begin* to see a benefit, that's a much harder sell and invites the kind of nonsense that sparks videos like this one.
This seems to be an argument for formalising 'skunkworks' into an orgs budget that would prototype things the org would like to see in future. At the end of a small project, the expected benefit is improved internal knowledge of the domain (including information to help management with future decisions pertaining to the domain), as well as a reference implementation for when it comes time to integrate with other components.
Otherwise you get either:
a) stagnation as no-one wants the large upfront cost and risk
b) traditional estimate nonsense
c) people treating enhancements like technical debt, essentially hiding the time they spend on it so no-one can tell them no.
and I've seen all 3 in my current project.
@@Jedimaster36091 Thanks for responding to your own initial comment. Fantastic. How was the team doing? did you do that story counting unofficially while the team was doing its own stuff, following the old process?
For those Agile advocates claiming estimations are waste, I have a question. Are you comfortable to sign contract for building your house with a construction company, that will tell you no price and time estimates? How do you choose from three different offers, none of them provided price neither schedule. When you will be doing next reconstruction or will be relocating, do not ask for price neither date.
The second interesting thought is to get out middle management, as they are only asking for estimates and chasing people until they burn out. So people will hire themselves, onboard themselves, figure how they want to work themselves, decide their performance and compensation themselves, thousands of people in company will decide their tools and strategy themselves, and take everyone will automatically take legal responsibility for compliance and if audit comes the auditors will speak with hundreds of people at the same time.
As much as I like certain ideas in this talk and feel inspired, some seems really stretched to a fantasy land and quite risky if implemented. All well known organizations which implemented flat model failed so far and returned back to management lines. But I am curious to hear about success stories if you know about organizations which implemented these ideas and how they worked out after several years.
As well, saying that one can not improve on estimating is a false claim. Few will still get overestimated, most will still be underestimated , but all that with lower margins of error.
"I've done big form before, 13 points, usually layout issues, need to add more work towards responsive layout, more effort validating). Oh, it's a 3 field form, 5 points then. Still needs to be tested and all, a bit more than fixing something simple (2-3 points), or updating a label (1 point)"
Not that hard, isn't it?
I train my teams to use story pointing to discover impediments. Whatever is blocking or slowing down the story from being done usually falls into one of four categories, Process, Scope, Unknowns, or Communication. If the story is large in scope it needs to be split into smaller stories. If there are unknowns then plan a spike for the iteration instead of the story. If there are communication requirements to the customer or another team then plan a meeting instead of the story or insist the 3rd party join the coding session. All other impediments left are usually around process. These are the constraints that limit flow and are the only things that can theoretically "speed up" development by removing them. So for me and my teams story points aren't for estimation, they're for evaluating impediments and implementing solutions. The goal is then to have every story be the same point value which leaves us with story counting as the way to project.
So more akin to a Kanban?
That sounds interesting, and my question is why you use Story points for this instead of just impediments?
Because it's all BS abstraction that are necessary for these agile coaches to have job security.
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.
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.
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.
I would just say estimates are similar to something you say I will score 80 % marks in the final examination.
And then you try to and study your best to achieve that target.
But you get 95% or you get 65%
Even if you score 95%, you are in problem you really underestimated and overdelivered.
Even if you score 65% you are in problem you really overestimated and underdelivered.
The first situation will not always work in the positive note. The L +1 will eventually understand this and will start expecting more and more and will force you bring the second situation which is where you start burnouts, start loosing comfidence and start underperforming as your moral will be down
The second situation will be considered as the performance issue.
Software development is not the smooth journeey like you are travelling in Aeroplanes where time is predictable.
It is like traveling in the bus on the roads where you are very likely to face traffic jams, accidents, signals, rough roads etc…Imagine you dont have any kind of google maps or here maps…
Its like we need to draw the maps on our own..on our brains..
You may get into wrong direction, you may find shortcuts ..but you dont know unless you realise.
Sometimes realisation comes after the problem is solved.(we should have went in that direction , but now we have reached the destination, there is no way to change the path and the quaility of the code is hampered..)
Another example is how can you judge the quantity of water in the well just by looking at it from outside it unless you see the bottom surface?Is it possible?
I will say irrespective of applying the any best possible techniques, still you cannot expect the developers to be perfect at estimates..
Its not about how long it should be how best it can be done.. I would say, rather than seeking the false promises from the developers and trying to fulfill them by making them spend sleepless nights and make them sit for long hours a day, I would say if we concentrate on deliver less , but deliver quality. Customer would be happy to wait ..
Initially code should be as scalable as possible in order to make the future related requirements easy and pluggable.
Eg. I have to develop a JDBC utilty which establishes connection to the various databses configured.
I would have very easily done that within 30 mins by establishing the connectivity by hardcoding each and every step without caring for future connections.
But what if I make the code scalable by introducing the connection factory and pass get the desired connnection by passing the 4 properties in future?
It took me 1 hour instead of the 30 mins in first approach, but for every future databse connections, it took me hardly 5 mins ..
So 30 mins for every connection like for 5 connections, it can take 150 mins vs 60 mins for 1st connection and 5 mins each for evey every subsequent connection to different different types of databases like 60 mins for 1st connectivity + (4*5 ) = 60 +20 = 80
So which approach is good ? Time or Quality?
Obivously, better quality code would help you achieve the targets better in the future even at the good pace.
It will be better if target is quality and code scalability rather than sitting sticking to the said time target and achieving the false promises.
Fulfilling the false promises will result in false deliveries and false happiness.
So I have the counter question for you, how can you underestimate the power of code quality and code scalabity just to fulfill the expected estimates?
So instead of ‘Say and Deliver’ I would follow ‘Deliver and Say'!
I completely and utterly agree. The people against #NoEstimates gets bad estimates... but they get bad late or bad software.
The "count the stories" approach might have worked well because the team was good at estimating equal-sized stories.
You're not considering the fact that if you feel like you need to do that, you aren't using stories & agile correctly in the first place. What should be measured is the value delivered for clients, not the work required to do it.
@@kspfan001 So, we have a bad link on a page. To fix it, it's 15 mins job (change, test commit... nothing is less than 15 minutes). The value to the business - well, the frigging web page doesn't work, users can't login. So, what is the value for the client? Huge. So tell me, how many story points?
I completely agree with every single word spoken in this talk. I myself have been increasingly skeptical and critical about estimates from many years now.
After reading Thinking: Fast and Slow and The Black Swan, it is clear that estimates and predictions simply do no not work. Simple as that. There much evidence in the scientific community in form of research and observation of empirical facts that they do not work. I won't go into the details here because entire books have been written on this topic, but the simple idea is that we don't know about the future and how the countless variables change during a period of time.
If estimates or predictions work only some times, it is random chance. We could as well just toss a coin to decide on how long something will take to complete or how much effort and resources it will require.
As for the hurt story points and estimates cause for teams and projects, I can tell many tales of people closing incomplete cards in their ticketing systems just to meet a sprint deadline, merging broken, untested, subpar code, pretending that the tasks were completed within the allotted time, then creating further cards to do further work.
Or, people feeling destroyed because sprint after sprint some cards are always spilled to the next sprint, cause bosses graphs to look bad, and endless meetings to discuss "how to prevent this to happen in the future", just to have it happen again in the next sprint.
Story points and sprint deadlines are a good way to implement means on how to destroy team moral, bore the hell out of people, and make people lose the sense of meaning by forcing them to do things they know from experience don't work and is a waste of time, life and countless hours of work.
But for people who want to pay programmers less [1], it is a good tool.
1. www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html
The idea that you always work with unknowns does not make any sense. It is true that you can not predict the future, which is why unknowns are always a part of the estimations as additional time. If you can't hit a 90% accuracy with your estimates, then you are either inexperienced, so you don't know how long things take for real, or you don't have enough time to properly evaluate and plan for what needs to be done.
Not pushing back on rushed projects is always on the developer, and you should always write technical debt when code is not of the correct quality due to financial decisions. Providing realistic estimates eliminate this problem almost completely, but it requires you to actually know how to estimate and stop trying to make happy guestimates.
"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."
Ha! couldn't agree more on that. But the issue is not so much in estimation, but rather in committing stories for a sprint. Kanban anyone?
I say the same since 15 years or so. I seem not to be alone with that.
I liked this presentation at first. Mr Holub gives a great and very passionate presentation. I like that.
But really this is about #AntiEstimates (a tag that doesn't exists) and not about #NoEstimates. The latter is about exploring alternatives and doesn't say "Don't use estimates", but rather "Use estimates if you cant find something that is better; here's a few things we've tried".
I think there's a difference.
Great presentation - thanks
+Marcus Hammarberg: I suppose I am #AntiEstimates :-), though of course you could cast the projection techniques I discuss as a kind of estimate. You're absolutely right that #NoEstimates is more about having the conversation than coming up with a "solution," however. I see this talk as a part of that conversation. Being a practical-minded guy, I've layed out my solution, but it's certainly not the only approach!
+Allen Holub Thanks for the comment and just to restate; I liked the presentation - very thought-provoking. Thanks
If you watch the video again at 1:40 you will that got the wrong picture. This video allow me to say it needs an open mind and its hard to grasp when we are used to do things in a certain way. As humans we don't really like change.
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.
From my experience: Estimation is most accurate when it takes more time then solving the ticket.
Is that counterproductive? Ahhh! Sarcasm!!
Good one!🥂
My team lead said this once: I could finish the ticket now (during the backlog review meeting LOL).
This dude really knows what he is talking about
This is the explanation i was looking for ! Thank you sir.
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.”
What a great presentation. I love how you are cutting through the bullshit, well done.
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.
I have never gave a good estimation to my managers...
Interesting concept, he covered one issue with the perspective which is project feasibility but in my experience, what the business often need to know cost.
Can we afford this project? Do we need to re-budget our business priorities? Do we need to hire more engineers and so on.
Developer may be engineers but also service providers like lawyers and lawyers define their costs as time. The presenter explained how we can ignore time estimates, but what about the real issue cost?
You can't predict that and you should stop, that's the whole point. It will cost exactly what it costs to develop and guessing that upfront is always going to fail.
You missed the point.
This man knows!
I've done this myself and it works, but it works when you have mostly similar size, well understood stories
#noestimates isn't a methodology, it's a labor movement.
I once had a manager who told me he could account for unknown unknowns.
What a superpower. Thanos + his fully equipped gauntlet would be mad jealous
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).
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?
Wow, thank you! the most valuble video.
it's great, counting sliced works are sufficient for projection & minimize wastes with estimation
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.
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
This just reminds me of what Eric Brechner says in his talks about Kanban. Basically what you do in the model he teaches is break things up to chunks of roughly the same size, do your best to maximize flow, measure how many get done in the measured period of time and what falls in your lap is a rough projection. Yes, obviously the process of breaking things up into pieces of roughly the same size is estimation but to me it sounds somewhat doable. So if the stories are roughly the same size...
Definitely doable :-). At least I've been doing it for a while and it works great. Frankly, narrowing all your stories down works even if you still insist on estimating. I coach Scrum teams to do it, too. Not only is it much easier to gauge the work, but breaking up a big story into small ones uncovers all sorts of low-value, unnecessary work (which you then don't have to do!). I just came across a set of great planning-poker cards (estimation.lunarlogic.io/). There are only three cards, labeled: 1, NFC (No...Clue), and TFB (Too...Big). Bought several sets to hand out to Scrum teams :-)
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.
I think that story points have a great value, but not for forecasts.
Namely: during planning poker, when all devs reveal their numbers, a discussion is triggered with the outliers. This makes for knowledge sharing.
but then the method is somewhat of a lie: people are told that story points measure something meaningful and it's all too easy for managers to interpret them as such regardless of the side effect that performing the task invokes discussion. indeed simply breaking down tasks as a group without resort to story points will be just as fruitful for one will notice where there is not enough information to reliably predict anything. the devil is always in the details.
I have been saying this for years. Sad I only have one up-vote. great video.
So we went from Time -> Story Points -> # of Stories. Cool.
In real terms, how is # of stories any better? I wonder. 👀👀👀
@@errrzarrr same poop in a different hand, but you are "saving" on discussing whether the story needs to be broken down or not, because you didn't assign points to the story. Thus, sprints are going to be even crazier!
Fantastic presentation. Very few comments for a great video like that.
"Sprints" are the opposite of working in a steady pace.
Did you ever see a runner doing one sprint after another, to run a marathon? You won't because it is nonsensical. But that is what sc(r)um does teach us!
Totally agree! Kanban wins marathons.
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
@23:00 restated.... "The developers at the race car drivers and the managers are the pit crew."
This is great, except I didn't get a very clear answer to how to answer the questions:
1) When do you think you can have this done by?
2) We'd like to launch this year, do you think it's possible?
How do we respond to managers who ask that?
Rocky, One of the problems is that's not an agile way of thinking about things. When presented with a time box (anything from a sprint to a year), the question to ask is "how much value can we provide in that time period," and of course, you learn as you work, so the things you'll be working on change. Even the Scrum Guide says that you should work that way. Your first question presupposes that you can entirely define a project up front. An agile approach says: lets build the smallest, most minimal thing we can get away with first, then based on actual feedback from actual customers, we can incrementally expand it. So, you get a set of stories, narrow them down to a day or two, and then work on them in order of value. "This," then is the next story. You'll be done with it in a couple days.
Re your second question, that's the point of doing dynamic planning using a cumulative-flow diagram. It's making a projection based on actual measured progress and the size of the backlog, and not only answers your question directly, it gives you options if you don't like the answer. If the projected date is too far into the future, you can adjust scope and see the impact on the diagram.
If your managers have fixed both scope and time, and they're not willing to add teams, that's a classic death-march, iron-triangle situation. That's just bad management performed by people who don't understand the fundamentals of business, and there's no solution to that particular problem :-). In agile projects, scope changes constantly. That's what agile is about, accommodating changing scope.
Thanks so much for your reply. I will take your advice to heart. I do have an unrelated question: is it possible to take the number of the stories completed against the amount in the backlog per the last three sprints from one project and apply it to a different project from another customer but the same team? Or must we always start out not knowing then, once we have 3-5 sprints done, we can project the rest of the timeline?
Well, your average number of stories completed per week will probably transfer, assuming that you're not changing technology or team composition. The main thing is that, to transfer the metric, you need consistency. On the plus side, I've found that the average "settles" pretty quickly, so if you get it wrong at first, the number will adjust within a few weeks.
@@AllenHolub If you had mentioned Kanban at any given point, I could buy that.
Meanwhile, as a dev, who figure out how to use estimation to my own advantage, i.e. "look, it's 120 points, and we are not accepting more story points, we draw a line here". This won't work with a number of stories, you would need to discuss in detail what each story entails, to make sure we would not overcommit to the sprint, and maybe break down into more stories when accepting work to sprint, and the only thing you would be saving at this point is writing down a number.
So, I wholeheartedly disagree that we should stop estimation in scrum setup. In Kanban, sure thing - no more than 5 active stories on the board. I'm about to pull one. let's have a quick chat.. Actually, most productive time I have experienced was when we ran in Kanban style. Was awesome, motivation through the roof.
Allen, I love your talks and wished there were more people in my company who have seen it. However I have one question regarding projections and the size of the backlog. If you say that probably 70% of the backlog could be deleted as we don't know yet if the stories are correct at all, how can I then do a projection? In theory the top 10 items are the ones where a projection might be useful, but then we're talking about probably one month of work, but not the whole project. Would be happy to hear your thoughts!
This only happen if you mix strategic and operational items in one backlog. If you understand the requirement process then you know that only actually decided requirements end up in an operational backlog and that backlog is reviewed every week, or at least every sprint, before you put things into the next iteration.
Only if you don't have a proper requirement process will you have backlog stuffing, and even the team should remove things unless it is likely to be included in the next couple of sprints. The business need should be recorded elsewhere anyway, as that is not a requirement.
This is a fantastic talk thank you!
The correct answer to estimates is always "ten years". Will it really take ten years? Of course not. But if take longer than estimated, this is always a huge problem. It's never a problem if you are done early. So with an estimate of ten years, you will always be done early. See, there is a fundamental truth about all developing processes: You can either define the end of project by a feature set, then the project is done when the feature set has been reached but it is unknown how long that will take. Or you can define the end of a project by a time frame, then the project will end after a given amount of time but it is unknown what feature set you will get up to that time. But what you cannot do is defining both, feature set and time frame, as that will almost never work, that's only wishful thinking and in the end either condition won't be met. I call this the Heisenberg Principle of Development. So make up your mind what is more important to you, when the project is done or what feature set it will have and then go along with it. As the video says, if you are unsure, set smaller goals. Go with a small feature set and see how long that takes or go with a short time frame and see what you get, then adjust your future decisions accordingly.
I find the idea intriguing, but I see several significant issues with it:
The backlog projection graph presented seems suitable for projects with a defined start and end point. This typically applies to projects ordered by a customer, where there is an agreement to deliver a finished product. In such cases, projecting the end date is crucial. However, many software projects are ongoing with regular releases. How can you project a subset of features or stories using this method?
Building on the first point, managers often require estimates for specific epics, but this technique is a statistical tool that views the project as a whole. Using this graph, it is difficult to project meaningful information for a specific epic or story.
Thank you, great talk 👍
No doubt that the talk and the presentation was great. I really liked this #NoEstimates, but i still feel it is incomplete. It is like we are only discussing the problems in different ways, models and techniques, in every talk and articles over and over again (lol, i am doing the same rn). Those projecting techniques are good too, but when the client asks you 'by when are we up and running', and i guess we would reply them saying 'we will let you know when we are done, when we are done'. May be i am naive, just started as a junior developer. I believe client will not wait unless we provide them with all the dimensions and time being one of them. If i misunderstood something please let me know, like to learn and grow.
Why are the Managers there? Managers should be able to manage clients and not try to manage employees...! If you look in google maps, even it is not able to predict the right amount of traffic comming on the way. It just shows the current status on the map..! If anything changes the predictions too change..!
"When are we done?"
"We can release now if you are happy with the feature-set that is available"
@@defeqel6537 hi thanks for sharing that. The question asked "when are we done", seems like it was asked after some development was made. But what if it was asked in the start?
@@9paradox The honest answer is "we don't know", but I realize many customers don't like this answer. The presenter mentions in other comments the need to also educate clients on agile practices.
If you play the video from 24:30, Allen discusses how to solve that problem. Given the current state of the backlog, and the current RATE of stories being implemented, you can reliably tell the customer when the product will release. You then have a few choices: a - kill the project; b - reduce the backlog; c - add more resources to change the velocity of the story implementation; or d - accept the date. The point at which the backlog line and the story implementation line intersect is essentially your date of completion.
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.
Counting stories is not enough when your stories varies in complexities.
I'm guessing the stories average out pretty quickly. Especially if well defined.
Excellent talk, thanks for sharing!
Very interesting, I liked it a lot.
I miss something. It is OK to count stories, but sizing the stories is very important too. I worked in a company where the size of a story was huge, so having something done took a while and having this projections was not possible in a short time.
"Take the torch and speak with the bosses"... I do not know how to do it in a company that resists to change and where people above know better that developers how to do the job.
A story should not be large. Break it down.
@@vladpredovic6956 The moment you assessed the story as large, you did estimate, be it in T-Shirt: "This story is L". The whole #NoEstimates breaks as it is unbalanced message with radical rhetoric. People need some common vehicle to communicate simplified understanding in this case of a story, just like you have said "story should not be large", but what large means? What it in my opinion it is not large but small? That whole conversations is underline an estimation of story size, a guess.
What we should advocate is rather to no use estimations for planning tool, nor for making crucial decisions, or being aware of how reality unfolds. For that predictions methods mentioned be Allen Holub are far superior.
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.
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?
Never been in a place where the bosses, the risk takers, told me 'hey take your time, you delivery when you deliver'.
Bosses are risk takers? Wat?
If you think estimating games are about the number at the end, you do not understand what we want to do with estimating.
Enlighten us
@@SM-ok3sz Yes, pleas enlighten us with your understanding.
@@anonymous_anonymity enlighten deez nuts
Really like this. Do you have an alternative that Big Corporates will accept? I need to know. :)
Probably not. I've pretty much given up on Big Corporates when it comes to agility. They're just not interested in doing anything other than using the word "Agile" in their advertising. There are a few glowing exceptions, but they're as rare as hen's teeth 😄
Perfect. Start of a new project tomorrow - gonna try it out :) Thanks, Mr!
Did it work?
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
Fibonacci is used other than normal sequence because the difference in number is well reflected in human mind for Fibonacci
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)
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?
I love this man.
It's shocking this knowledge has been available for nearly a decade and we still spin in circles.
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
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.
10th time watching
I love this talk, but it relies, that the stories are written properly and with all requirements to count them, and in my point of view this is the real problem(know what they really want); new requirements are popping up after the program is implemented as defined. Due to a lack of knowledge between the business and the dev team. I think that this is the biggest problem (btw. I work in an env. where the business does have no clue about the effort of rewriting a whole workflow 😅)
As I have gotten more into Lean Agile i've been using cumulative flow, control charts and monte carlo simulations , mostly as a hobby as I'm not yet ready to replace my old world view, but i'm compelled. How do you know you have all the stories is my question? And if most of your stories at the bottom of the backlog are nonsense, how can you trust that number?
I had the exact same question.
You don't need ALL the stories. All you need is the rate of change of added stories and consumed stories (do not log defects as stories...more on this later). If it helps, you can treat the backlog as candidate stories...until you associate them to a release. The planning that you saw on the screen is around a release, with a fixed number of epics (don't change the epics of a release if you can help it. This will simplify your scope and also help prevent your team from getting "whipped by WIP"). The accuracy of "When you will end" will get better and better the more sprints you do, but you need at LEAST 3 to have some sanity and confidence that your 2 rate of change and where they intersect are "good enough". Couple tips here: #1 do NOT log defects as stories they will confuse your backlog and you. When a defect is discovered (lets say through exploratory testing as hopefully you have automated TDD, the defect is validated from your product owner or the team that is actually a defect in the scope of that story....and then you fix it....immediately. Defects take the highest priority, the team stops what they are doing and you fix it. #2 Not having defects in your backlog will provide better data for your rates of change from stories. #3 To account for "time to handle defects" just reserve %20 of your teams capacity for defects in sprint planning. So if your team can typically only handle completing 5 stories in a sprint....cool, they only commit to 4 stories so they can predictably take care of defects.
I also wonder about the same thing and unfortunately I cannot answer it, but I want to note: if you are not sure you can count the number of stories, there is surely no point at all in estimating points/time for them.
Really interesting approach
I take story over functional requirements any day. I heard way too many of "Oh, I haven't thought about that" way too often when people come with functional requirements. The same might happen with story needs to be discussed, and groomed, and how is implemented is discussed and narrowed down. Often during those discussions when we would observe innovations coming from different people on the team
.
re: OCD: BS argument. Retrospective takes care of this. Scrum relies on self-managing teams. During retrospectives, we look back, see what worked, what didn't, and we agree on improving how things work, by adjusting the process.
Bottom stories, ie wild fantasies: those are epics. big chunks that are there for visibility of how far we yet need to go to the finish. Normally, they are not fantasies, since these are pretty generic.
Funny thing, what he talks around @21:50 is how scrum suppose to work, and what scrum is trying to address.
As well, he does come across like a person who has never done product feasibility study from a business perspective. You do need to have some idea on how long before the product can be shipped, how many devs you'll need to implement, etc, thus estimation.
"Counting stories is enough": Again, epic vs story. as well, having points in stories helps to not overcommit, especially when you have stories broken down, and some stories with higher number because they do not make sense to break down even further, but it's still going to take longer or is more complex (ie, breaking down would be true waste)
Of course, if there would be no committing for sprint, then it's not an issue from this perspective, which I would love to see being gone - I hate committing to the sprint with passion.
Always under-promise and over-deliver!
A thousand likes for this!
how will you know when to stop accepting stories to the sprint? so, you will end up discussing on what the task entails, thus still pretty much doing exactly same work as estimating, but you would just save 1 second in writing down the number. Yay.. a win! /s
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.
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?
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.
You are always betting. You have to make estimates. Every action or inaction is a bet.
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)?
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.
Maybe we could say that (copyright Eisenhower):
"Estimates are useless, but estimating is indispensable" ?
:)
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.
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 :)
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.