#NoEstimates (Allen Holub)

good morning everyone my topic today is no estimates and but I what I mean by that is what that hashtag actually says which is to say we need to just stop doing all estimation now is that estimation has no value at all and I am hoping over the course of the next 45 minutes or so I can convince you that that statement is true the main problem with estimates is that estimates are always based on guesswork you're always guessing you can make a claim that estimates are based on observing past behavior but the fact is is that what you're implementing is something that hasn't been implemented before so any kind of measurement that you've made of something that happened in the past is not going to impact what you're doing now which is to say you're always guessing now the problem with those guesses is that they're also always wrong which is something that we all know but for some reason we behave as if we didn't know that we imagined that the estimates that we come up with have some kind of validity to them even though we know deep down inside that they don't everybody that every programmer that I know at one point or another has complained about how bosses take their estimates as if they're bolted in concrete and it's because we know that the estimates are bogus but if we know that they're bogus why don't our bosses know that they're bogus and my answer to that is they do so we have a very dysfunctional situation here where everybody is relying on something that doesn't work and we know as a fact that it doesn't work now what is whoa who's known mostly for the mod programming seen in my programming scene came up with this hashtag a couple years ago now it's been a while to try and start a discussion around this problem so my take is not exactly the same as Woody's and in fact woody would be happy with that is that the point is to have a discussion not to have a dogma it's around the surrounding estimation and my take is basically that estimation leads to dysfunction it leads to situations where one is working ridiculous numbers of hours without needing to where we have irrational schedules which are destroying everything around us they destroying our lives in every way possible more to the point they're making the projects that we're working on not not succeed simply because people don't have the energy that they need to do good work is that this all falls into this to an agile notion of a continuous pace of a steady pace this idea that you can sustain your pace indefinitely that you're working at a rate at which the you never get exhausted you never come in in the morning so tired that you can't actually get work done and the problem is that as soon as you put estimates on the scene you can't have a sustainable pace anymore because as soon as you have estimates you have deadlines and as soon as you have deadlines you have people working 18-hour days in order to meet those deadlines and as soon as you have that you have a dysfunctional workshop so estimates are causing lots of dysfunction at the at the process level if you will now the other problem is the one that I was alluding to a moment ago is that a boss asks you how long something's going to take and of course you come up with a wild ass guess you have no idea how long things are going to take but then your boss takes that and says oh that's a contract he said it you know you said well maybe we can have it in six months and the boss comes to you six months later and says why isn't it finished right so that is also a kind of dysfunction and that's a dysfunction and impacts the business in serious ways because this boss is making business decisions based on a misconception based on thinking that this number that you just pulled out of a hat has got some kind of reality to it now Steve McConnell who's in a way the guide of estimation or is in some ways because he came up with a lot of rules that people use to do estimation came up with the notion of trying to resolve this problem by putting percentages putting putting probabilities on testaments what he would say is at the beginning of a project what you have to say is here's my estimate but has it has a 20 percent chance of being accurate now that's good from a mathematical point of view the problem is is that people don't understand what 20 percent means this is 20 percent we have a 20% chance of success here if we point this gun at our head now if we work for a few months McConnell would say things get better we can say to our boss we have a 40% chance of succeeding well that's 40% it still doesn't look very good to me but about 60 I'm still not particularly happy here even at 80 I'm not particularly happy here right is that in other words if you have to put percentages on estimates in order to present them in any kind of truthful way we have the problem that people don't understand how percentages work they don't understand what these numbers actually mean so what we're really doing here is just gambling and I think building a business on gambling is a bad idea some people done it admittedly but I certainly have it I can't even put money into the stock market because I always lose money so trying to build your business on this kind of notion it's just really a bad idea now the next input into this process is the much-maligned chaos report it's maligned because a lot of people disagree with the approach that it takes and says the numbers are a little different but everybody who complains about it they come up with numbers that are in roughly the same category so let's look at the actual chaos report is that the basic notion of the chaos report is that 80% of projects either fail outright or are so late as to be called failures that's a big number now the problem with the chaos report is that Institute's panic people yell oh my god there is a software crisis well the fact is that there actually isn't a software crisis the real problem is that we just don't know how to estimate stuff in other words it's not that things are late 80% of the time it's rather that we don't know how to do estimates 80% of the time so our estimates are wrong so the point of the chaos report is not that 80% of things fail the point of the chaos report is that we don't know how to estimate stuff and if that's proof of that fact so again if we have proof of something and we base our decisions on misinformation on something that we know to be false then we have failed in pretty significant ways so we just have to the fact that we don't know how to estimate and move on is try and do things in ways that don't require estimates in other words the real software product crisis is not that we don't know how to estimate or that our estimates are wrong but rather that we're building code that doesn't do anything useful but it's the estimate that's driving that now I will contend that hitting your estimate has no value in other words if the estimate is so important that you set up milestones that are driving your project and you are judged based on the fact that the thing comes in on time and within budget well if you've built the wrong program you have not succeeded in doing such of value at that camp at that point so one of the other dysfunctions that comes out of the estimate culture is that we're focusing on the wrong thing we're focusing on time rather than focusing on what the programs are actually doing and it's in fact what the program is doing that's the important thing so the agile guys came along and they came up with this notion of the story thinking that the story would somehow address this issue the problem is is that if you look at the way that agility works in most organizations they don't really do agile right which is to say people have notions about how things ought to work and estimates are firmly ensconced in that in those notions so they look at something like agile and they try and interpret it in a way that works according to their worldview now if you think about a story what is a story a story is a short narrative that describes your users doing something that produces a valuable result if you're doing agile wrong and this happens a lot a story is just a disguised way of say of describing a functional requirement right so menu saying as a user I need a menu item in order to be happy that's not a story right a story is actually a narrative it happens at the domain level it's actually a narrative but how do you estimate that in other words we have this problem that the story has become the central part of the way that we're putting our software together but it's a very amorphous kind of thing right I can I can estimate a bunch of functional requirements because I know how long it takes me to make a change to a database or to add a button to a piece of existing code but you don't have functional quirements in agile systems although you have the stories so that brings brings us to something called story points is that the story point was an attempt to reconcile these two opposing world views in other words a story point was a way of estimating the idea was that you attach a numeric value of some sort to the story based on the difficulty of doing it the problem is is that itself leads to dysfunction now first of all let's look at what story points started out being right this quote is from Ron Jeffries who came up with the idea of story points and notice that the whole point so to speak of a story point is to obscure time because they had a bunch of managers that were obsessed by time as many managers are and agile is not a time driven process so they came up with the notion of story points in order to get this guy to not have to think about time anymore so that they could tell him something dime like so he'd be happy and go off and do his stuff make his charts and stuff and they could meanwhile get work done nonetheless that guy still wanted estimates so what you ended up with was the madness of taking story points and turning them into time and we've all seen that right one point is about half a day and two points is a day or so and three points or six points is going to take most of the week and right is that in other words what we're doing is we're starting off with a thing that existed in order to not talk about time and suddenly we're talking about time again we're back to estimating now you could solve that problem is that you could use a difficulty scale that was not easily convertible to time and if any of you are forced to do some kind of story point thing I strongly recommend that you do this is to forget about the numbers the numbers are too easy to misinterpret they're too easy to to to turn into estimates again this at least is giving us some piece of useful information about the story that we can use to prioritize it the other issue is velocity which is also tied into this velocity is another destructive force in organizations right velocity is usually interpreted incorrectly as some kind of measure of efficiency it's what it is from my point of view is a ratio the ratio between the time it would take to do a project if you had absolutely no distractions at all and you were working on it eight hours a day and you were doing nothing but working on it - the amount of time that it actually takes as far as I'm concerned it's a it's a decimal number in the range 0 to 1 it's a percentage now what that means among other things is that the team cannot do much to change velocity in other words if you look at the velocity between the ratio of perfect of a perfect environment in an imperfect environment the only way you can make that number larger is to improve the environment in other words the reason velocity goes down is usually because the institution has put obstacles to the way in the way of work and those obstacles those processes forms that you have to fill out and stupid stuff that you have to do right is that those are the things that are bringing your velocity down they're slowing you down nonetheless in a dysfunctional company you'll see lots of situations where the managers are saying we have to prove the velocity of this rather what they say is the this team has to improve its velocity as if the team is made up of slackers that are sitting around reading comic books all day and if they just stop doing that they could actually get some work done well that's not what's happening usually what's happening is that the organization itself is putting in is putting in place the very obstacles that are slowing the teams down but when you bring that notion of velocity into play all of a sudden we're back into the realm of estimation so the notion of points per sprint we have to earn points I hear this a lot right it will will be credited with our points because if not our velocity will go down and then our managers will get upset right is that's really really really wrong thinking because it just gets us right back into the role of ridiculous estimates right because the points have no meaning either any more than a time-based estimate would have so the real problem is that estimating software is like estimating physics is that we're thinking about estimation in the wrong way we're imagining that it's like a manufacturing process how long will it take to develop that warp drive oh I don't know 10 years well 10 years from now I'm going to hold you to that you don't have that warp drive ten years from now your head is going to roll right is that it's not we're not we're not estimate estimating something that's estimable why we would do it is another interesting question now I think it has to do a lot with ritual the batter here is exercising or ritual he swings a certain number times and then he just gives up he steps back and then he wags his hands around and he touches the tip of his bat right this is all ritual this has nothing to do with actually being able to hit the ball the interesting thing here is look at the catcher right the catcher is going is having a conversation with the umpire he's not paying all that much attention you know he's saying hey Fred how are the kids and meanwhile the batter is doing stuff but the catcher and the umpire are having nothing to do with that want to go for a beer after work yeah sure is that the you know it see what see what's happening here there's a disconnect in other words between the people on the team is that the fact that there is ritual in play is actually doing damage to this process in the sense that the catcher is completely disengaged and he needs to be engaged so we have a word for this which is a passive compulsive disorder right in other words what we're doing here is setting up a situation we're performing the same ritual over and over and over again in the hopes that it will achieve useful results but that ritual does not there's no difference between the ritual of estimation and the wrist ritual of locking your door seven times as you leave it's it's equally irrational and it achieves exactly the same result which is to say not a good one motivation is fear in other words it has to do with spending money I can't invest a million dollars or a million pounds at whatever unit of currency you want to use in the large project without an estimate I need to know whether it can be done in a certain amount of time well there are lots of ways to address that that don't have to do with estimation so for example well instead of talking about a year-long project let's talk about a month long project that's way cheaper and let's build it for you I'll guarantee that will be done at the end of the month at that point you can look at what we've done and we can make some sort of decision about whether we need to continue or not in other words what I'm doing here is reducing risk by thinking in an agile way right if we're doing the wrong thing we have the option of fixing it here really early it's not like we're going to go a year and then nothing's going to work and more to the point we can give accurate projection so that's the direction in which I'm moving in terms of this talk is I want you to not be thinking about estimates but to be thinking in terms of projections so let's move in the direction of projections imagine that you're looking at your backlog the backlog is just a big pile of things that have to be done to do lists is that in an agile shop the backlog is a list of stories so it's the list of the stories that have to be completed here we have a hundred unit backlog which is unacceptably large though I was just talking to Jules this morning he was talking about a 400 story backlog and a project he was working on which is bordering on insanity now why is that well the top ten stories are probably correct they're good enough that I can pick them off the heap and start implementing them and when I implement them if I succeed I'm probably not wasting my time the next store it's next 30 stories or so they're definitely going to change but they're probably just going to change a little bit there's still elements of correctness there in other words we'll learn things in the process of doing the top ten stories that impact the way that the story is underneath it on the backlog work the bottom stories though that's just wild fantasy we have no idea what's going on down there so much is going to be learned and so much is going to change in those top 30 stories that the bottom ones just have no rel at all which means that what we should really do with those bottom stories is just toss them any backlog that's got a hundred stories on it has got something really wrong with it because we're talking so much in the future that we can't predict if you think if you take the bot something in the bottom story and you throw it off throw it out and it turns out to be necessary well you can always add it back it's not a big deal now going back to the original list then time spent doing estimation is going to depend on the value of the story so up at the top time spent doing estimation is mostly waste because you're going to produce these things so soon that what value does the estimate have there's no point in estimating them you go underneath there and it's just hideous it's moved into the hideously wasteful category because not only are they going to happen relatively quickly but we don't know what we're going to do so no matter what our estimate is it's going to be based on on incorrect assumptions about how the software how the software works what the software has to accomplish and of course the ones on the bottom were in to mentally deranged cat it mentally deranged territory right is that there's no reason an estimating down there and this tweet from Paul clip is I think very much to the point because he's talking about re estimating stuff down on the backlog there are many companies that insists that we provide story point estimates for every item on the backlog all hundred of them well believe me putting an estimate on item ninety-eight is a complete waste of time and re estimating ninety-eight because something changed above it that really is in the mentally deranged area it's just a complete waste of time so how did all this come about it all came about I think since I need somebody to blame from Frederick Taylor who came up with his notions of scientific management this was all based on assembly lining assembly line work and it was all based on the idea of the time manager on an assembly line the guy with the stopwatch and this was a guy from management it was somebody that was walking around with a stopwatch checking the amount of time that it took to do everything on the assembly and that if things didn't work you then sat down with the time boss and the time boss told you how to change what you do in order to improve the time on that stop now we manufactured things like that for a long time and it didn't actually work very well and things got way better in the 70s when taiichi ohno came along at toyota and came up with the basic concepts of lean manufacturing the most important concept in lean manufacturing to my mind is the notion that you give the watch to the people who are doing the work in other words you empower the people on the assembly line to decide how they're going to work there's no longer a manager with the stopwatch rather you say to the guys who are doing the work do the best job you can and figure out how to do that now I know that if you say that to a bunch of programmers they're not going to be doing estimation because they know that estimation is worthless the only reason we do estimates is because our bosses forces to you give the power to the workers and they don't do that anymore now power to the workers sounds awful socialist but believe me Toyota is not a socialist organization is that this works now there are a lot of other good things that came out of lean first of all the developers are now controlling time which means that an estimate is under the control of engineering you will never have a situation given a lean philosophy where somebody outside of the engineering organization will tell you how long you have time is entirely under your control now because of that the business side has to do something and its responsibilities to decide what to build not how long it will take but what it will build you get to say how long it's going to take now that's still a kind of estimate so we're just moving in the right direction but there's important changes that happen when you think about that in other words where there's no longer an estimate with a manager who is forcing you to hold on to that estimate the guy the time manager with the stopwatch has gone away in other words nobody is ordering anybody around anymore so this changes the management structure of the entire company this one piece of thinking is that there's nobody who's forcing you to meet your schedule that person is gone just disappears from the scene in fact it affects the organization as a whole if you don't have a schedule what are the managers actually do right most managers what they do is they control the schedule right that's their job right they make charts they keep spreadsheets they check today attention to time they make sure things are happening according to schedule well if you don't have a schedule what does a manager do and the answer is nothing so you can just get rid of them that makes the organization a lot smaller and while we're at it we can just flatten the entire class or the class I keep Bladon the entire organizational chart of the entire org higher hierarchy so agile organizations in lean organizations tend to have very flat hierarchies like that now there's another important change though if you're giving control over how you do work to the people who are doing the work then the people who are at the top of the hierarchy have a completely different role what it does is it flips this whole picture upside down in other words management becomes a support role it's the role of the manager to support the people that are doing the work so if you have a management situation in an agile world what will happen is the managers job is to take away all obstacles to work everything that the team needs it's the managers job to make sure that they get that he's not telling them what to do he's helping them do what they need to do so this all falls out then of getting rid of that stopwatch the other issue that's important is this notion of waste also important part of lean lean is all about eliminating waste well what is waste and Ono's definition is if it doesn't put value into your customers hands it's waste estimation is waste in fact a lot of the stuff that we do in an organization is waste because it has to do with the internal machinations of the organization it does not have to do with actually putting valuable stuff into the hands of the customers so we need to eliminate waste whenever possible now what about estimates I would argue that all time spent estimating stuff is waste because no amount of time making an estimate is going to put a piece of valuable software into the hands of your customers it's just not going to happen so the estimates have to go into our trash can to because they're not providing value you do have to do accurate projections though in other words we are running a business here it is the case that it is the fact rather that time matters sometimes right as things have to be done on time is that if it's something is not finished by a particular trade show then the company is going to lose half of its income next year if you're doing something that's going to regulatory framework it's got to be done by a certain time so we have to have projections in order to run the business but the reason we want those projections is to make two decisions the first one is shall we kill the project that's a decision you want to make very early in other words you want to be able to say this project is really just not worth doing is that I can see right now that we're not going to be done on time the other thing that the other decision that you might want to make though is that if you see that you're not going to be in on time is should you add more people now you can't add people late that's that's Brookes law right adding people to a late project makes it later but if the project's not late adding people can work so in both of these cases this is a business decision that we want to make early in the life cycle of the product now if you think about estimation approaches though you don't know that you're in trouble until the estimate slips so much that it's obvious that it's obvious that you're that you're in trouble which is much later in the project cycle so from a business point of view estimates are not helping here because it doesn't allow us to make these decisions early enough what you do need to do is count that's the one thing you need to do in order to make projections you need to count we're programmers so we count in hex now to look at counting I want to resort to some slides here as Vasco kindly let me use a couple of his slides in this presentation as a condition of that I said I would plug his book which I'm happy to do so this is Vasquez book I strongly recommend that you go to this website you can read the first chapter Vasco has done a lot of really interesting work about no estimation by actually measuring stuff I actually collecting actual numbers from actual projects and looking at how they play out and they play out in really interesting ways this is a cumulative you have seen something like this but these are very valuable pictures what the columns are on the left is each column represents the total number of stories this is an agile project but it could be function points or anything else you want to use for an estimation if you will in this case it's stories the total number of stories that comprise the project when a story is finished it goes down into the blue area when the story is unfinished when it's on the backlog it stays in the red area note that the back notice that the backlog gets larger it always get backlogs always get larger so we can make projections using a cumulative flow diagram that are valuable in other words if you project the total number of stories and then you also look at the rate at which you're completing stories the place where those lines cross is the time that the project is going to be finished everyone following how this is working mathematically this is pretty valuable now the interesting thing about this diagram is to compare this two different kinds of diagrams this one is is showing the story points is that these story points are all the total number of story points is in the 70ish range and these story points are computed using a Fibonacci scale which is one of the ways that people like to do it is numerically they say you don't say one two three four and five four story points you use a Fibonacci sequence because if the number if you can't predict if something is harder than it's a lot harder it's not a little bit harder but interestingly if we just go to story points being one two three the result is almost identical so the question is why are we messing around with Fibonacci story points the really interesting statistic though is this one all that Vasco is doing here is counting the number of stories or to put it another way if you're going to insist on doing story points all stories have a point value of one now I guess this is estimating but it's not really estimating all we're doing is counting and if we superimpose these three pictures on top of each other a really interesting observation happens is that they've all come up with more or less the same time for completion we're within seven or eight percent here so what this is telling me is that we can do something really complicated we can do story point estimation based on a Fibonacci sequence spending hours and hours and hours and planning meetings trying to figure out what the story point value of every story is or we can just count stories and we get the same number in either way but if we're just counting stories that takes all of 20 seconds so eliminating waste is definitely a possibility here if you took a look at the time spent producing these estimates as being waste well we don't need them I can't just count the number of stories and I can make my projections and if that number is too far out right if this this area down here is too far out I can kill the project or I can add people because if you add people then the slope of this line will get steeper and then we'll have an earlier delivery date so counting stories is enough we don't need to estimate anything all we need to know is how much work we have to do now the other the other slide the Vasko uses that I really like is this one we're talking about how predictive is it right what we have here on the left is the output of the team the actual output that is both predicted and actual everyone see what I'm saying here in other words ridiculous certain amount of output we look at the actual and we find here that 20% more happened than we expected when we were using story points as it means a prediction against story points are a kind of estimation on the right here though we have again almost exactly the same result but all that he's doing there is counting stories so in terms of the predictive power of counting stories it's almost identical to the predictive power of working with an estimate and this is only three iterations we're looking at go to five iterations the numbers are almost identical in fact the number on the right is identical everyone everyone following what I'm trying to get out here in other words the the point I am making is that counting stories is more than good enough if what you're trying to do is make accurate predictions from a business point of view and that doesn't involve any notion of time at all it's just counting now let's spend a moment and talk about how you might organize things in order to get yourself out of the thrall of estimates and be able to plan properly because of course business people want to plan as soon as you say that we're going to get rid of estimates they throw their hands up in the air go oh my god I can't do that is I have to be able to plan so how do you plan with your no estimates best way of planning I know is to use something called a story map this story map is a bunch of index cards that are just keeping track of our backlog of the things that we want to work on stuff on the left is is too much too undefined to actually work on it stuff in the middle of stuff that we actually can work on it and stuff on the right is stuff that we that's already finished it's the stuff in the middle that matters the the map is organized according to priority priority goes down as you go down the map and time as you move to from left to right so when you're working with this story map what's what the layers of the map are important is that we have our epics across the top the really big stories things that are so big that they're going to take months to implement underneath that we have the large the set of user activities that comprise that epic if I need to do stuff with email I need to write emails I need to send them I need to look at them underneath that we have the actual stories organized in priority order the one possible example of how that might play out is that we might be doing some kind of account management system right so the green stories across the top they're the large activities we need to create accounts we need to modify payment information so on so on and so forth now the story map is used in order to decide what to do next and you decide that by working horizontally across the map in other words if I take one row across here that's going to give me the most important stories for all of the user activities in all of the broad areas that the program has to cover so we have a fully releasable product at this point it doesn't do all of this low priority stuff under here but that's fine this is a way to plan now planning of course is a fluid thing is that as we're working this diagram is going to change will be adding stories and removing stories and adding entire new categories so this is not a static document which means that that chart we were looking at a moment ago is going to be changing all the time too but this gives our bosses this gives the business people a tool that they can use for actually planning business activities which is something that they used to be doing with estimates but there's no estimation of time here it's all just stories and we can do our projections by counting stories and here's an example of a bigger one it just shows you some of the categories that would exist in them in a larger project so that's our best planning tool is just the story map all right so let me sum up them first of all estimation is entirely waste everything that you do that's estimate related is time that could be spent programming and since the estimate isn't getting as much since the simply counting the number of stories gives us exactly as much information as we would get if we were spending a lot of time doing numeric estimates and time based estimates why waste time doing time based estimates there's no value in it the second issue is that estimation is actively destructive to the organization is that the culture that supplies estimate that surrounds the supplying of estimates makes the organization work in dysfunctional ways it forces people to work overtime it forces people to work on things that are not important in order to meet time time-based deadlines it's just a immensely destructive force in the in the universe of work the third issue is that counting stories is enough that you don't need a lot of time that all you have to do is count and that's a very simple thing to do and it doesn't require any kind of deep thinking but it provides you with the projective tools that you need to run the business and then the other thing the last piece is that if you always do the most important thing first then you always have something of value so you go back to that story map and the whole point of the story map was to figure out what the most important set of things were so that you would arrive at a functional programming program functional programming you could arrive at a functional program that did everything that it needed to do to be useful as quickly as possible and again we don't need estimation for that so I'll finish up here with a call to arms is that the way we make these changes is just by refusing to do stupid stuff or more to the point the way changes like this happen in an organization is by us explaining the sorts of things I was just explaining to our bosses and getting them to try it it won't take much time to prove your point here remember the slides from a couple minutes ago we were talking about three sprints five Sprint's doesn't take very long to prove your point but the way this is going to work is by us pushing for it not by imagining that somehow the people above us are going to sudden and suddenly become enlightened and start doing the right thing so I will end with an exhortation then which is that you have to go out and hold the flame and then convince the other people in your organization to do the right thing here so thank you very much and have a good conference

Channel: Allen Holub

Views: 113,050

Rating: 4.9302325 out of 5

Keywords: #NoEstimates, Allen Holub, Agile Software Development (Industry), lean manufacturing, Keynote (Software), Software (Industry)

Id: QVBlnCTu9Ms

Length: 37min 45sec (2265 seconds)

Published: Sun Jul 05 2015

Reddit Comments

[u/crabsock]

summary

40 minute video

[u/DingBat99999]

I recently coached a team to try not estimating for 6 months. They liked it so much they're still doing it 2 years later.

​

We tracked cycle time and then used Monte Carlo simulation to forecast the number of stories we would likely complete, with say a 70% level of confidence, in a given amount of time. We presented this to the product owner and said "here's your budget. Do whatever you want with it".

​

The product owner then selected his top priority stories and off we went. He swapped out stories as emergencies and new priorities arose.

​

Our forecasts turned out to be considerably more accurate than our up front estimates.

​

My advice it to ignore the #NoEstimates bullshit. I wholeheartedly believe that you can work effectively without estimates. I just don't believe in the #NoEstimates movement. I find them to be unnecessarily controversial in their pronouncements and they tend to over-complicate things. If you're already estimating with enough accuracy that everyone is happy then for god's sake keep doing it. If you're having trouble, then consider switching to cycle time and Monte Carlo estimates.

[u/[deleted]]

I've been on both sides of the manager / developer fence and I'm a certified scrum master fwiw. What you need is not to get rid of (time) estimates or planning, but to have common ground and understanding about what an estimate actually is. It's not a promise, a contract or anytning else like that - It's just a (hopefully informed) guess. The developer has the responsibility to keep the manager up to date about the stuff they are working on, and to inform them about any significant hurdles or surprises that come along the way, and the manager needs to listen and plan things according to that. And, things can and do need to be able to change along the way and there needs to be slack time in any estimate to cover for the minor unforeseen things (that do not require a sprint restart or a redesign or whatever).

In any professional development environment, on some layer of abstraction, there is both a budget and a business need. These things do need to be projected, tracked and be accounted for. Software engineering is not a special snowflake in this regard.

[u/NotExecutable]

How does this work in other industries?

Surely software development isn't the only case where a need for planning collides with unforeseeable work.

Also, the approach he postulates at around the 16 minute mark doesn't work for all IT projects. If you want to replace that old COBOL system of yours, you really can't deduce much from a month or two of development progress. And perhaps it's a situation where you need feature parity with the old system before you can start using it. That's where the 80/20 rule will come in and kick you in the groin while it shatters the projection from the early months.

I'm not convinced that failing to keep up with the projections is better than failing to keep up with estimates. Bad managers will react to both in the same bad way.

[u/RockleyBob]

My scrum master cares more about the communication than the number of hours left on any given task. She cares that I am updating that number on a daily basis, and that I am communicating any impediments to my success during standup. She cares that there is an ongoing dialogue, and that I am using the tracking tools that our company pays for to the best of my ability. If a task needs more hours, she wants me to add them in Jira. If a task suddenly becomes unblocked and all of the sudden I just have tests left to write, that’s not a problem. Adjust the hours. Did we put too many stories into this sprint? That’s ok, let’s talk about why that keeps happening. Do we constantly get saddled with tasks that are unrefined and lack sufficient technical guidance from the architects? She’ll go and bitch at them for us.

She is a good scrum master.

[u/jrhoffa]

#NoHashtags

[u/michaelochurch]

I wonder how the fuck it became socially acceptable for bosses to ask for estimates when underlings aren't allowed to ask their bosses, "How long do you think it'll be until I'm making your salary?" Reciprocity, yo.

[u/MetalSlug20]

I do think its funny that even though we are supposed to use story points, in my manager's head he still sort of maps it to TIME. and points things accordingly , lol

[u/LifeIs3D]

To me it's really simple. An estimate is just that. The tough part is getting mgmt, planners, customers to truly realize and accept this.

And then to get the developers and testers to truly understand and believe that everyone else has reached that understanding. Otherwise they will still refuse or pad estimates.

Also, never estimate optimal weeks, or efficient work hours. Estimate normal weeks with normal disturbances... That's the only thing we really have and know.

Finally, be roughly right instead of precisely wrong. Two years ahead you don't need dates or times. You need a half year, possibly a quarter to aim for. Narrow it down as you get closer and have more work done - giving you a better understanding of the rest of the way.