Fantastic presentation. One of the most valuable videos on TH-cam about software development IMHO. As Allen says at the end (and I so agree with): It’s up to developers to get this happening on our projects - management’s not going to understand the dangers of estimating until WE educate them!
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.
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.
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.
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.
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...
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.
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.
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 :)
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.
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.
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.
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.
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.
Probably not. I've pretty much given up on Big Corporates when it comes to agility. They're just not interested in doing anything other than using the word "Agile" in their advertising. There are a few glowing exceptions, but they're as rare as hen's teeth 😄
I 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...
The one big pushback I've seen from management when someone have suggested no time estimation, is that sometimes projects are sold for a fixed price and management can't offer a price to the customer before having a time estimate. Wat would be a good comeback to this argument? Is this type of pricing model just not a good way to sell software?
This 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.
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.
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.
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.
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.
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?
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?
How would you have any projection in any real agile environment when you are creating just enough of a product backlog to start working on a couple of iterations? How would this work with a 6 month+ projection since you don't want to build a backlog of stories for 6+ months.
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)?
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
I've done this myself and it works, but it works when you have mostly similar size, well understood stories
8 หลายเดือนก่อน
15:46 - How do you give a price offer to a customer who has a bunch of things he wants to get developed (like redesigning a website or some admin functionality enhancments) and he is not interested in trying stuff out for one month and then reiterating tickets, he just wants to know the total cost so that he can ask multiple companies and compare prices?
Same. Come up with a list of stories. Count the stories. Multiply the number of stories by the estimated time for a single (most complex) story. Note that in an agency a lot of the implementation can be reused in different projects improving predictability. If you have to make something new, which you have no idea how to estimate, tell it to the client and request time for a POC. This way you won't be guessing too much and jeopardizing the project and your reputation.
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).
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 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'!
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?
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?
thanks for the video! how can we predict completion of an epic that hasn't been started yet, with the help of the cumulative flow diagram? when we don't have any history of how quickly the stories are getting done?
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.
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.
The amazing thing about estimates is that they are paradoxical: you need to spend time in order to estimate time! But the best time spend is the time spent actually working on the project. So since we as developers are doomed to spend time in order to estimate, it's better to spend this time to get that history (velocity?) that we need in order to produce this cumulative flow diagram!
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 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 how do you make projections at an early stage of a project when a couple of stories at the bottom of the stack are low priority and are, therefore, not as small as the higher priority stories? If you break down low priority epics at an early stage, it's waste. If you don't break them down, how do you include them in the projection?
The stories at the bottom of the stack don't matter much---they'll probably change considerably before you get to them, if you ever *do* get to them. Also, the stories-per-period metric (which is an average) settles down pretty quickly; typically, within a few weeks. That metric carries over from project to project of course, so you don't even need those few weeks for an established team. (And you should not be splitting up teams simply because a project is over. That's a serious dysfunction from an Agile perspective.) So, the main points are: (1) You're working with averages, so the size of an individual story doesn't matter much. (2) You'll probably never get to the stories at the bottom of the stack because, odds are, new stories that enter the backlog will be more important. I wouldn't worry much about them. (3) If you don't have many stories in the backlog, spend a few minutes and "narrow" them (reduce their scope) so that your averages will be more fine grained.
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.
I wonder what data is the "100 item backlog" story starting at 17:00 based on. Sources would be nice to mention, even if it's just "my personal experience".
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.
I'm not sure what you mean by "product." Traditional work-for-hire contracts don't work very well. That is, if you have a very detailed specification, you could do a very-detailed analysis and come up with an estimate, but that approach rarely works. Since things always change (or go wrong), you have to set up an adversarial relationship with your customers (either you're padding to cover eventualities, which is to say that the customer is overpaying, or you have to eat the problems, which is to say that you're underpaid). So, you notion that you can accurately predict what it will cost to build software in advance is not correct. You can't. More to the point, since requirements always change during construction, you'll probably deliver a suboptimal product. There's no benefit in delivering the *wrong* thing on time and within budget. Finally, your customer is shouldering an enormous risk with this approach, given that they probably won't see working software until months (or years) after project inception. None of this is good. The #NoEstimates approach is different. You build incrementally. Consequently, your contracts have to be structured around working incrementally. I like two-week intervals. At the beginning of that two weeks, I sit down with my customer and we decide on a "story" to implement, and I deliver in (about) two weeks. I then get paid, and we move on to the next story. The customer can easily predict an overall budget based on the number of stories, and can predict release dates using the CFD that I demonstrate in the video. Working incrementally gives us the flexibility to build something truly useful; the *right* thing. Whether this is "agile" or not is debatable. Certainly, short cycles and incremental development are an important process of all the agile approaches that I know. However, "Agile" is way more than that. Though I wouldn't recommend it, you could work incrementally using a series of mini waterfalls, for example. What you can't do. Ever. Is accurately predict the cost of a software project up front, no matter what approach you use. The only exception is that a team is building a duplicate of a project that the same team built using the same technology for the same platform, and not that long ago. People who say that we just have learn to create more-accurate estimates, are delusional. We've been trying to do that without success for 60 years.
Thanks very much for your reply. I'm very interesting with the points that counting the number of stories. And, we make sure that building the right things from the beginning and giving the valuable things rather than wrong things on time and within budget, I agree with you. I meant that product is the final-product. I know that nobody look at documentation, and even programmer don't know that exists. However, from the customer perspective they want everything within a limited budget. For me, the problem is that most of the customers they don't know what they want to do at the first time, and they will tell us what they want until they see the product, another is we can just only estimate base on the experiences, if we come up with something new, we have no idea how to estimate that. But, the customer alway keep asking about how much and how long will it take in the OVERALL? You said that counting the number of stories is good enough for accurate estimation. Yes, it could be if all of the stories that we've done it before and all the team know how to do it. And one more question, what did you mean by top priority is building the most important thing first? How can we know that it's important? from customer point of view or from your assumption? Thank you again.
That's exactly why you want to work incrementally. It should take no more than a couple weeks to start getting software into your customer's hands, and you should continue to release every couple weeks. You should then incorporate their feedback into what you're doing. Yes, many customers are used to big up-front specifications, but at the same time, they hate having to wait a year before they see anything (for good reason). You have to negotiate your contracts to replace that big up-front specification with regular small releases and the ability to change what you're doing. I'd recommend supplementing my video with Vasco Duarte's "No Estimates" book (goo.gl/qlqElO).
@@AllenHolub Interesting discussion thread. And all are valid points! However, if a consulting agency is bidding on a project of a prospective client, with the aim to win that project, to get the foot in the door, how would the agency set the bid/pricing for this project without some form of estimation?
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.”
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 :-)
Hmmm. I'm willing to give it a try but it seems to be based on people/teams that don't don't understand story points. From my experience if done properly sizing works pretty well. Story counting would seem to have just as many issues (waste) as sizing - doesn't the story size matter? What happens if they are wildly different in size? What about the sizing proviso that if a story is bigger than x you probably don't understand it? I'm not sold
Thin vertical slices is a best practice. In doing so, the items tend to be consistently small. Even if there is variation, a few outliers will obey the law of averages. The same is true for changes in capacity. Then one can apply the cone of uncertainty to project a range of what is possible which is more realistic than any hard number or long-range project plan, SWAG estimate. HTH
@@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!
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.
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.
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
29:30 So you work three months without a plan to make a "projection" that says "2 crossing lines tell me" the project will be finished six months later. Based on the example, this means that you have to work a certain amount of time to balance out peaks in the projection. That sounds logical, but in practice it's unrealistic. Because for three months (or whatever time) NOONE knows when the project will be "projected" as finished. Uncertainty in time means uncertainty in costs (resources). And that's not what the client wants and that's certainly not what you want as a company. If you are unsure about the availability of your resources, then you cannot run a company. In my experience from over 25 years of project practice, this way of thinking is wishful thinking and has nothing to do with practice. When you calculate an assignment or take part in a tender, you have to estimate (calculate) your offer. And if you have committed yourself to an offer, then you have also committed yourself to a scope of services. There is no possibility to say, Ok then you just get less customer, because we made #noestimation. Planung without control is nonsense, control without planning is bullshit.
Virtually nothing that you've said is correct. You start collecting metrics immediately. They will settle to the point of being useful in a few weeks. You can start projecting immediately, and you modify those projections daily based on actual work performed. Planning in an Agile world, where requirements are in constant flux, must by dynamic. In that world, software projects are never "finished." The questions are, when can you start getting feedback by deploying, and how soon can you produce revenue, and when does it stop being cost effective to continue development. If you're working in an agile way with very frequent releases, the first two of those determinations happen rather quickly (weeks, not months). A #NoEstimates approach is an agile one. If you're not Agile (and it sounds like you're not), then the approach has little value. For example, your notions of "tender" and "commitment" are fundamentally waterfall thinking, based on contracts that codify that thinking, and of course, a #NoEstimates approach won't work in that context. You cannot work in an agile way under a waterfall contract---you contract has to describe the way you actually intend to work. If you can't educate your clients to accept Agile, then either abandon any hope of being Agile yourself, or find a different set of clients. You may have "no possibility" given your current client set, but there are many thousands of contractors working with many thousands of companies worldwide successfully using Agile approaches. "25 years of project practice" is of no relevance if your practices have not changed in 25 years. Agile is a radical departure.
@@AllenHolub This is the conflict with reality. For example, if you offer solutions in Germany that are suitable for public administration or large companies, then these are not agile projects, because these are not agile organizations either. And the solution to "find suitable customers" is not a solution, but also wishful thinking. Do I accept 2 large projects for 20 million EUR or 10 small projects for 5 million EUR? That is what medium size companies have to deal with and then they have to deal with the consequences. We are not able to impose an agile organization on our customers. The description says "particular" which is misleading from my point of view, I would say "only" fits better.
@@kayom2000 Well, you're arguing that you can't be Agile in Europe. I know of many people who are doing just that (being Agile in Europe), so I have a hard time accepting your argument. However, if you're saying that you, personally, can't be agile because you, personally, can't find any clients who are willing to work that way, so be it. As I said, the approach doesn't work in a waterfall world.
@@AllenHolub He does not actually say you cannot be agile in Europe. He says there are clients that are not agile. Especially the public sector is geared that way: fixed budgets and public tenders with quite rigid framing. This is quite universal in the entire hospital sector across Europe, for instance.
@@carlerikkopseng7172 The public sector spends a year's worth of budget just to decide on a contract, so they can hardly take a "let's give these guys 3 months, and if they are not good enough, try this other company"-approach.
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.
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.
Do you not assume in your proposal that all stories are issued right from the beginning of the project? It is also a waste, because some of the stories you create may turn out that you will not start them at all because the conditions/requirements will change.
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.
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.
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.
Did you know Steve? I did (though not well). He was, sometimes, a tyrant, but he was well aware of the iterative nature of good design. He wouldn't have put up with slips in production schedules, but design is not production. You cannot be creative on a schedule. Software development is a creative pursuit. I'm sorry that you seem to be working in a shop that thinks that cracking the whip is essential.
Steve Jobs had a whole thing on pointing your devs in the right direction then getting out of their way - you'd never see Steve Jobs telling people to story point things. Also Steve Jobs said in an intetview that he admitted working for him during Apple's early days was the most stressful period in most of his employees lives, and they couldn't have kept up that pace for longer - most of those people left when it became to much. And he was paying them an enormous amount amount of money.
+nikotwenty Not exactly. A burndown chart is typically used during a sprint to track the tasks that you'd perform during the sprint. I don't much like those because the set of tasks always change as you work, but the burndown chart will treat that as a negative, not as a trigger for a scope change. That is, a burndown is a tool to determine that we're "on schedule." The CFD is project-scope, not sprint scope. It's also tracking stories, not tasks. It's main purpose is to see when you need to adjust scope.
+nikotwenty I suppose you could use a burndown for your backlog, but there's not much point. Backlogs always grow. The problem is prioritizing the stories (and discarding the low-priority ones). A burndown won't help you with that.
I do like most of your points, but I think it's unfair to trash burn down charts as a meaningless and valueless waste of time, and then proceed to praise cumulative flow diagrams, when at heart, they are essentially the same things. (as way too often happens in "agile methodologies" and practices, where you have one thousand names for the same thing, just because you have one thousand chaps wanting to sell their "product"...) It' s pretty sad to see how the values of the agile manifesto have been corrupted into a means to sell "development methodologies products and experts" fighting to impose their conventions...it really reminds me of the "diagramming wars" at the the time of Waterfall Development and Documentation Fetish.. The same warts, just with different names.. I suggest you watch your own talk "The Death of Agile" :) and "Agile is Dead" by Dave Thomas ...and then rethink about the "righteousness" of cumulative flow diagram over burn down charts.. :) This being said, I absolutely love your "attitude"!
No. They're not the same at all. A burn-down chart is just telling you how much you need to do in the current iteration. They focus on tasks, not stories, and, in theory, tell you whether you're "on track." The worst thing about them is that they perpetuate the notion of a Sprint "commitment," a word that you won't find in the current Scrum Guide (which uses the word "projection"). If the burn-down rate changes, people treat it as a problem rather than as a normal result of working in an agile way. That is, you will learn as you implement, it's natural for new tasks to appear as a consequence. The Scrum Guide says that you should work with the PO to change scope at that point. Burn-down charts don't encourage that way of thinking.
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 soft deleted ~70% of our backlog 2 years ago and no one ever noticed. It was amazing!
Or they had already resigned themselves to none delivery
hahahaha
Lol
😀...
@Mark Lindell, you still continue to do soft delete of backlogs?!
You silently removed items in backlog - they didn't notice.
They silently resigned - you didn't notice either.
Fair game I bet :D :D :D
Fantastic presentation.
One of the most valuable videos on TH-cam about software development IMHO.
As Allen says at the end (and I so agree with):
It’s up to developers to get this happening on our projects - management’s not going to understand the dangers of estimating until WE educate them!
Completely agree - but it is a VERY hard sell... on the surface, it sounds so easy, so simple and valuable to estimate...
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.
The first video that I found about no estimates that answer how to plan for on time release. Thank you a lot.
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.
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.
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
@Zealy 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.
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...
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.
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.
Finally someone with a sensible story. Hats off.
I'd love to subliminally play this in the ears of PMs while they slept.
Inception!
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 :)
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
Great presentation Allen Holub. One comment regarding Lean organization, from my experience it is often used as a way for upper management to control engineering team through direct reporting.
You deserve more subscribers. Especially CEOs. They need what you preach.
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.
this is the most legit guy i have seen on agile...
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.
I've been saying this since the 1990's and everyone mocks me. Now I can tell them Allen Holub agrees with me!
Or they can mock both of us :-)
@@AllenHolub At least I'll finally be in good company. Loved your talk. Will take in more soon.
You know the Fuck Agile websites, right? Mr. Holub said gave the middle finger to Agile without raising his hands.
I hate those refinement sessions where you spend an hour or so just on estimating story points
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.
This is the explanation i was looking for ! Thank you sir.
I completely and utterly agree. The people against #NoEstimates gets bad estimates... but they get bad late or bad software.
Really like this. Do you have an alternative that Big Corporates will accept? I need to know. :)
Probably not. I've pretty much given up on Big Corporates when it comes to agility. They're just not interested in doing anything other than using the word "Agile" in their advertising. There are a few glowing exceptions, but they're as rare as hen's teeth 😄
I 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...
The one big pushback I've seen from management when someone have suggested no time estimation, is that sometimes projects are sold for a fixed price and management can't offer a price to the customer before having a time estimate.
Wat would be a good comeback to this argument? Is this type of pricing model just not a good way to sell software?
This 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.
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.
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.
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.
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.
Wow, thank you! the most valuble video.
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?
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?
How would you have any projection in any real agile environment when you are creating just enough of a product backlog to start working on a couple of iterations? How would this work with a 6 month+ projection since you don't want to build a backlog of stories for 6+ months.
Even with forecasting, user stories are still used in the example. Isn't having user story points imply we are still estimating?
That's what it is. We still playing wizards game here 🧙♂️🔮🧿
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)?
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
I've done this myself and it works, but it works when you have mostly similar size, well understood stories
15:46 - How do you give a price offer to a customer who has a bunch of things he wants to get developed (like redesigning a website or some admin functionality enhancments) and he is not interested in trying stuff out for one month and then reiterating tickets, he just wants to know the total cost so that he can ask multiple companies and compare prices?
Same. Come up with a list of stories. Count the stories. Multiply the number of stories by the estimated time for a single (most complex) story.
Note that in an agency a lot of the implementation can be reused in different projects improving predictability. If you have to make something new, which you have no idea how to estimate, tell it to the client and request time for a POC. This way you won't be guessing too much and jeopardizing the project and your reputation.
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).
I do agree that estimations are “guessing” but isn’t velocity a part of scrum and agile?
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 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'!
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?
Where was this recroded?
This man knows!
This dude really knows what he is talking about
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?
I say the same since 15 years or so. I seem not to be alone with that.
Thank you, great talk 👍
Is it still applicable in 2024?
thanks for the video! how can we predict completion of an epic that hasn't been started yet, with the help of the cumulative flow diagram? when we don't have any history of how quickly the stories are getting done?
How long should story take?
This is a fantastic talk thank you!
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.
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.
The amazing thing about estimates is that they are paradoxical: you need to spend time in order to estimate time! But the best time spend is the time spent actually working on the project.
So since we as developers are doomed to spend time in order to estimate, it's better to spend this time to get that history (velocity?) that we need in order to produce this cumulative flow diagram!
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.
Perfect. Start of a new project tomorrow - gonna try it out :) Thanks, Mr!
Did it work?
it's great, counting sliced works are sufficient for projection & minimize wastes with estimation
are we willing to be hired by 2 weeks basis and see how we work then extend another 2 weeks of our employment contract?
I liked this presentation at first. Mr Holub gives a great and very passionate presentation. I like that.
But really this is about #AntiEstimates (a tag that doesn't exists) and not about #NoEstimates. The latter is about exploring alternatives and doesn't say "Don't use estimates", but rather "Use estimates if you cant find something that is better; here's a few things we've tried".
I think there's a difference.
Great presentation - thanks
+Marcus Hammarberg: I suppose I am #AntiEstimates :-), though of course you could cast the projection techniques I discuss as a kind of estimate. You're absolutely right that #NoEstimates is more about having the conversation than coming up with a "solution," however. I see this talk as a part of that conversation. Being a practical-minded guy, I've layed out my solution, but it's certainly not the only approach!
+Allen Holub Thanks for the comment and just to restate; I liked the presentation - very thought-provoking. Thanks
If you watch the video again at 1:40 you will that got the wrong picture. This video allow me to say it needs an open mind and its hard to grasp when we are used to do things in a certain way. As humans we don't really like change.
+Allen
how do you make projections at an early stage of a project when a couple of stories at the bottom of the stack are low priority and are, therefore, not as small as the higher priority stories?
If you break down low priority epics at an early stage, it's waste. If you don't break them down, how do you include them in the projection?
The stories at the bottom of the stack don't matter much---they'll probably change considerably before you get to them, if you ever *do* get to them. Also, the stories-per-period metric (which is an average) settles down pretty quickly; typically, within a few weeks. That metric carries over from project to project of course, so you don't even need those few weeks for an established team. (And you should not be splitting up teams simply because a project is over. That's a serious dysfunction from an Agile perspective.)
So, the main points are: (1) You're working with averages, so the size of an individual story doesn't matter much. (2) You'll probably never get to the stories at the bottom of the stack because, odds are, new stories that enter the backlog will be more important. I wouldn't worry much about them. (3) If you don't have many stories in the backlog, spend a few minutes and "narrow" them (reduce their scope) so that your averages will be more fine grained.
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.
Fantastic presentation. Very few comments for a great video like that.
I wonder what data is the "100 item backlog" story starting at 17:00 based on. Sources would be nice to mention, even if it's just "my personal experience".
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.
If the point is that no estimation at all- especially in Agile, how could we answer to the customer when and how much the product is?
I'm not sure what you mean by "product." Traditional work-for-hire contracts don't work very well. That is, if you have a very detailed specification, you could do a very-detailed analysis and come up with an estimate, but that approach rarely works. Since things always change (or go wrong), you have to set up an adversarial relationship with your customers (either you're padding to cover eventualities, which is to say that the customer is overpaying, or you have to eat the problems, which is to say that you're underpaid). So, you notion that you can accurately predict what it will cost to build software in advance is not correct. You can't. More to the point, since requirements always change during construction, you'll probably deliver a suboptimal product. There's no benefit in delivering the *wrong* thing on time and within budget. Finally, your customer is shouldering an enormous risk with this approach, given that they probably won't see working software until months (or years) after project inception. None of this is good.
The #NoEstimates approach is different. You build incrementally. Consequently, your contracts have to be structured around working incrementally. I like two-week intervals. At the beginning of that two weeks, I sit down with my customer and we decide on a "story" to implement, and I deliver in (about) two weeks. I then get paid, and we move on to the next story. The customer can easily predict an overall budget based on the number of stories, and can predict release dates using the CFD that I demonstrate in the video. Working incrementally gives us the flexibility to build something truly useful; the *right* thing. Whether this is "agile" or not is debatable. Certainly, short cycles and incremental development are an important process of all the agile approaches that I know. However, "Agile" is way more than that. Though I wouldn't recommend it, you could work incrementally using a series of mini waterfalls, for example.
What you can't do. Ever. Is accurately predict the cost of a software project up front, no matter what approach you use. The only exception is that a team is building a duplicate of a project that the same team built using the same technology for the same platform, and not that long ago. People who say that we just have learn to create more-accurate estimates, are delusional. We've been trying to do that without success for 60 years.
Thanks very much for your reply. I'm very interesting with the points that counting the number of stories. And, we make sure that building the right things from the beginning and giving the valuable things rather than wrong things on time and within budget, I agree with you.
I meant that product is the final-product. I know that nobody look at documentation, and even programmer don't know that exists. However, from the customer perspective they want everything within a limited budget.
For me, the problem is that most of the customers they don't know what they want to do at the first time, and they will tell us what they want until they see the product, another is we can just only estimate base on the experiences, if we come up with something new, we have no idea how to estimate that. But, the customer alway keep asking about how much and how long will it take in the OVERALL? You said that counting the number of stories is good enough for accurate estimation. Yes, it could be if all of the stories that we've done it before and all the team know how to do it. And one more question, what did you mean by top priority is building the most important thing first? How can we know that it's important? from customer point of view or from your assumption?
Thank you again.
That's exactly why you want to work incrementally. It should take no more than a couple weeks to start getting software into your customer's hands, and you should continue to release every couple weeks. You should then incorporate their feedback into what you're doing. Yes, many customers are used to big up-front specifications, but at the same time, they hate having to wait a year before they see anything (for good reason). You have to negotiate your contracts to replace that big up-front specification with regular small releases and the ability to change what you're doing. I'd recommend supplementing my video with Vasco Duarte's "No Estimates" book (goo.gl/qlqElO).
@@AllenHolub Interesting discussion thread.
And all are valid points!
However, if a consulting agency is bidding on a project of a prospective client, with the aim to win that project, to get the foot in the door, how would the agency set the bid/pricing for this project without some form of estimation?
Had anyone done the story mapping method?
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.”
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 :-)
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
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).
@23:00 restated.... "The developers at the race car drivers and the managers are the pit crew."
Hmmm. I'm willing to give it a try but it seems to be based on people/teams that don't don't understand story points. From my experience if done properly sizing works pretty well. Story counting would seem to have just as many issues (waste) as sizing - doesn't the story size matter? What happens if they are wildly different in size? What about the sizing proviso that if a story is bigger than x you probably don't understand it? I'm not sold
Thin vertical slices is a best practice. In doing so, the items tend to be consistently small. Even if there is variation, a few outliers will obey the law of averages. The same is true for changes in capacity. Then one can apply the cone of uncertainty to project a range of what is possible which is more realistic than any hard number or long-range project plan, SWAG estimate. HTH
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!
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 love this man.
Really interesting approach
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
What a great presentation. I love how you are cutting through the bullshit, well done.
Excellent talk, thanks for sharing!
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.
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
29:30 So you work three months without a plan to make a "projection" that says "2 crossing lines tell me" the project will be finished six months later. Based on the example, this means that you have to work a certain amount of time to balance out peaks in the projection. That sounds logical, but in practice it's unrealistic. Because for three months (or whatever time) NOONE knows when the project will be "projected" as finished. Uncertainty in time means uncertainty in costs (resources). And that's not what the client wants and that's certainly not what you want as a company. If you are unsure about the availability of your resources, then you cannot run a company. In my experience from over 25 years of project practice, this way of thinking is wishful thinking and has nothing to do with practice. When you calculate an assignment or take part in a tender, you have to estimate (calculate) your offer. And if you have committed yourself to an offer, then you have also committed yourself to a scope of services. There is no possibility to say, Ok then you just get less customer, because we made #noestimation. Planung without control is nonsense, control without planning is bullshit.
Virtually nothing that you've said is correct. You start collecting metrics immediately. They will settle to the point of being useful in a few weeks. You can start projecting immediately, and you modify those projections daily based on actual work performed. Planning in an Agile world, where requirements are in constant flux, must by dynamic. In that world, software projects are never "finished." The questions are, when can you start getting feedback by deploying, and how soon can you produce revenue, and when does it stop being cost effective to continue development. If you're working in an agile way with very frequent releases, the first two of those determinations happen rather quickly (weeks, not months).
A #NoEstimates approach is an agile one. If you're not Agile (and it sounds like you're not), then the approach has little value. For example, your notions of "tender" and "commitment" are fundamentally waterfall thinking, based on contracts that codify that thinking, and of course, a #NoEstimates approach won't work in that context. You cannot work in an agile way under a waterfall contract---you contract has to describe the way you actually intend to work. If you can't educate your clients to accept Agile, then either abandon any hope of being Agile yourself, or find a different set of clients. You may have "no possibility" given your current client set, but there are many thousands of contractors working with many thousands of companies worldwide successfully using Agile approaches. "25 years of project practice" is of no relevance if your practices have not changed in 25 years. Agile is a radical departure.
@@AllenHolub This is the conflict with reality. For example, if you offer solutions in Germany that are suitable for public administration or large companies, then these are not agile projects, because these are not agile organizations either. And the solution to "find suitable customers" is not a solution, but also wishful thinking. Do I accept 2 large projects for 20 million EUR or 10 small projects for 5 million EUR? That is what medium size companies have to deal with and then they have to deal with the consequences. We are not able to impose an agile organization on our customers. The description says "particular" which is misleading from my point of view, I would say "only" fits better.
@@kayom2000 Well, you're arguing that you can't be Agile in Europe. I know of many people who are doing just that (being Agile in Europe), so I have a hard time accepting your argument. However, if you're saying that you, personally, can't be agile because you, personally, can't find any clients who are willing to work that way, so be it. As I said, the approach doesn't work in a waterfall world.
@@AllenHolub He does not actually say you cannot be agile in Europe. He says there are clients that are not agile. Especially the public sector is geared that way: fixed budgets and public tenders with quite rigid framing. This is quite universal in the entire hospital sector across Europe, for instance.
@@carlerikkopseng7172 The public sector spends a year's worth of budget just to decide on a contract, so they can hardly take a "let's give these guys 3 months, and if they are not good enough, try this other company"-approach.
Fibonacci is used other than normal sequence because the difference in number is well reflected in human mind for Fibonacci
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.
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.
Do you not assume in your proposal that all stories are issued right from the beginning of the project?
It is also a waste, because some of the stories you create may turn out that you will not start them at all because the conditions/requirements will change.
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.
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.
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.
I was wondering, if a developer would have told Steve Jobs that I can't give you timeline to finish this, would Steve have listened to him?
Did you know Steve? I did (though not well). He was, sometimes, a tyrant, but he was well aware of the iterative nature of good design. He wouldn't have put up with slips in production schedules, but design is not production. You cannot be creative on a schedule. Software development is a creative pursuit. I'm sorry that you seem to be working in a shop that thinks that cracking the whip is essential.
Steve Jobs had a whole thing on pointing your devs in the right direction then getting out of their way - you'd never see Steve Jobs telling people to story point things.
Also Steve Jobs said in an intetview that he admitted working for him during Apple's early days was the most stressful period in most of his employees lives, and they couldn't have kept up that pace for longer - most of those people left when it became to much. And he was paying them an enormous amount amount of money.
isn't cumulative flow diagram the same!e concept as a burn down chart?
+nikotwenty Not exactly. A burndown chart is typically used during a sprint to track the tasks that you'd perform during the sprint. I don't much like those because the set of tasks always change as you work, but the burndown chart will treat that as a negative, not as a trigger for a scope change. That is, a burndown is a tool to determine that we're "on schedule." The CFD is project-scope, not sprint scope. It's also tracking stories, not tasks. It's main purpose is to see when you need to adjust scope.
+Allen Holub ok thanks. I thought burndowns were story based too. guess I'll have to look again at them
+nikotwenty I suppose you could use a burndown for your backlog, but there's not much point. Backlogs always grow. The problem is prioritizing the stories (and discarding the low-priority ones). A burndown won't help you with that.
I do like most of your points, but I think it's unfair to trash burn down charts as a meaningless and valueless waste of time, and then proceed to praise cumulative flow diagrams, when at heart, they are essentially the same things. (as way too often happens in "agile methodologies" and practices, where you have one thousand names for the same thing, just because you have one thousand chaps wanting to sell their "product"...)
It' s pretty sad to see how the values of the agile manifesto have been corrupted into a means to sell "development methodologies products and experts" fighting to impose their conventions...it really reminds me of the "diagramming wars" at the the time of Waterfall Development and Documentation Fetish..
The same warts, just with different names..
I suggest you watch your own talk "The Death of Agile" :)
and "Agile is Dead" by Dave Thomas ...and then rethink about the "righteousness" of cumulative flow diagram over burn down charts.. :)
This being said, I absolutely love your "attitude"!
No. They're not the same at all. A burn-down chart is just telling you how much you need to do in the current iteration. They focus on tasks, not stories, and, in theory, tell you whether you're "on track." The worst thing about them is that they perpetuate the notion of a Sprint "commitment," a word that you won't find in the current Scrum Guide (which uses the word "projection"). If the burn-down rate changes, people treat it as a problem rather than as a normal result of working in an agile way. That is, you will learn as you implement, it's natural for new tasks to appear as a consequence. The Scrum Guide says that you should work with the PO to change scope at that point. Burn-down charts don't encourage that way of thinking.
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?
#noestimates isn't a methodology, it's a labor movement.
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