This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices.<p>They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines.<p>Then they admit that "delays are normal and expected" - so you're not meeting your estimates.<p>Then they admit that "they delivered something different" - so you're not building what you promised.<p>Then they admit that "they "spent too much time on non-deliverables" - so you're spending the last months pre-deadline working hard to catch up on something that is already behind schedule and doesn't match the original spec.<p>But it's all OK because they kept the stakeholders updated with frequent communication and conversations...basically the same result as if they had <i>not</i> estimated a date but instead focused on iterative delivery and constant feedback with the customer. Sound familiar?<p>> Suddenly, the whole team became focused, distractions were all gone, and we moved at a faster pace than I've ever felt the team do so.<p>Why was the team not focused & distraction free from the start?<p>How could you achieve this efficiency without needing a deadline hanging over your heads?
> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead?<p>Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher.<p>I don’t disagree that we should estimate, but I think we should be realistic about just how difficult estimating software projects is, especially now that we’re “agile”, which really means “there aren’t any explicit requirements but there <i>are</i> requirements, we just don’t know what they are and also they change every sprint so good luck”.<p>If we want to estimate software, we need to have more predictability. I can estimate that it takes three days to fix a bug, but what happens when I pull those covers back and see an unholy Eldritch abomination? I could redo my estimate, but what if I run into an arbitrary quarterly profit-driven date? “Well, just get it done.” Then we nail some more legs to the dog and the cycle continues.
I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt.<p>In Thinking Fast and Slow, Daniel Kahneman offers my favorite object lesson on the topic:<p><a href="http://txti.es/kahneman-outside-view" rel="nofollow">http://txti.es/kahneman-outside-view</a><p>He sums up:<p><i>This embarrassing episode remains one of the most instructive experiences of my professional life. I eventually learned three lessons from it. The first was immediately apparent: I had stumbled onto a distinction between two profoundly different approaches to forecasting, which Amos and I later labeled the inside view and the outside view. The second lesson was that our initial forecasts of about two years for the completion of the project exhibited a planning fallacy. Our estimates were closer to a best-case scenario than to a realistic assessment. I was slower to accept the third lesson, which I call irrational perseverance: the folly we displayed that day in failing to abandon the project. Facing a choice, we gave up rationality rather than give up the enterprise.</i><p>The suggestion that the enterprise should have been abandoned all together can be misinterpreted as fatalistic, even nihilistic. I take it to mean that you've got to do your research (the outside view), rigorously define your MVP, and then work from there. If your deadline is fixed, be ready to scale back.<p>His distinction between the inside and outside view is the key. For a project to have any hope of realistic timelines, it needs to be understood and the outside view needs to be applied.
My current employer switched from SCRUM to KANBAN. We're broken up into person squads. Epics are created by product by engineers are involved in kickoff and story breakdown.<p>We use KANBAN cycle times to estimate delivery dates. For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date.<p>It's important to note that we've convinced management that these are approximate completion dates, not deadlines. The dates are used for planning upcoming features and which squad will be free first to take it on. However, there's still plenty of adaptability.<p>Of all the places I've worked, this model is one that I've found to be the most productive.
I'm intuitively on team #noestimates but trying to have an open mind/not dig in my heels.<p>I feel like no one does a convincing job at communicating why estimates matter (and how much value you get out of how precise of an estimate).<p>Fundamentally, an estimate (or any piece of information) is really only of value if you're going to do different things based on learning it. E.g., given an estimate, you might:<p>* Prioritize one project over another based on ROI.<p>* Know when to communicate that something might be available to users (though that's still not <i>intrinsically</i> valuable, you have to have some kind of marketing/sales-cycle based reason or something that it matters).<p>* Know when to begin supply-line stuff so that a factory is ready to build a thing as soon as possible (but no sooner, since then maybe you're holding up parts of the pipeline from doing other things? maybe?)<p>I feel like so often people try to underscore the importance of estimates but don't say anything remotely close to the above. A lot of times it's just "this is important/urgent". Ok, so? If it's urgent then that's even more reason to start actual work instead of spending time planning, if you can't point to a concrete thing you'll do differently having known the plan.<p>Even when people do talk about the actual reasons for wanting an estimate, it's always totally in the abstract. The precision of an estimate is always on a "delivery day" level, even if that level of precision is totally unnecessary for what this particular estimate was used for.<p>I think the real reason for this amount and kind of emphasis on estimating really has to do with:<p>1. Deadlines make people work harder/faster.<p>2. It gives people sticks with which to measure people/teams.<p>I think #2 is mostly straight-horseshit. #1 is maybe somewhat true, but I think it's not nearly as good as other ways of getting people motivated to work harder which have fewer negative externalities (e.g., more autonomy, instilling more of a sense of ownership).
I have to have all of the control system software ready for a power plant the second construction is finished enough to begin turning things on and commissioning them. This frequently overlaps with electrical, mechanical, and civil works still in progress. Not starting as early as possible means not finishing as early as possible which means holding up the transition from a construction project with construction loans to an operating asset earning revenue with much more favorable financing, which is significant in hundreds of millions of dollars projects.<p>All of the software needs to be ready to start commissioning on an unknown date. A lot of the programming can’t start until equipment details are received, which makes the whole thing a game of identifying what information you need and pointing out that if you don’t have it by x date your deliverables will be late, or you’ll have to work overtime or bring more people on it which will cost extra.<p>Having a good estimate for how long each piece of the programming will take and what inputs are required to finish it is crucial to having everything ready to go on D day or a bulletproof paper trail of how you’ve been fucked over by other people who couldn’t deliver, because those liquidated damages are no joke.<p>To me time estimates are a major component of engineering.<p>Edit: remove snark
Cost, quality, and speed. Pick any two. You can’t have all three. There are several modes of delivery. Some projects have fixed delivery dates because it’s externally imposed. For example a regulatory requirement. Some are internally imposed - an executive imperative. Projects with fixed dates need dedicated resources and a highly functional scope management process. Others are “innovation/exploratory”. For example “let’s build a bitchen website”. What does that mean? What is the definition of done? This requires an agile, “integrate until we are satisfied or run out of funding” project that may or may not have dedicated resources.<p>No matter what, in a corporate environment you will need to be accountable to cost, which is simply humans * time. So some type of estimate will be needed.
This is such an important topic and missing skill in the tech workplace.<p>It's impossible to prioritize work without estimating the cost & value of projects, and teams that don't prioritize are always overworked, playing catchup and are unhappy.<p>What the author says about 'we shipped different functionality to what we planned' is really important too -- beginning managers aren't willing to have this conversation but scope de-creep is the only way to deliver quality work on-time.<p>It's not enough to play planning poker, you need to have ICs in the room for spec design and make time to identify & resolve unknowns before committing to features / timelines.
I'm fine with either time- or complexity-based estimates <i>as long as they're treated as estimates</i>. I've not worked at any software company that did.<p>What are the consequences of missing an estimate (especially one I did not create)? If it's "stay late until it's done" (with no OT because you're legally "exempt"), that sucks. If it's "your career is penalized, the same as if you were incompetent at the task itself", that sucks.<p>I'd rather go back to a low starting salary, and earn OT when my manager decides to keep me working late. The money isn't as important to me as aligning our goals.
I think it's good to write down your guess for your own future reference in improving your own guesses, and at some point you'll be good enough to do this and not get burned (as a contractor, I'm assuming).<p>I have been doing this a while and am not good enough to avoid getting burned without building in a 3-4x buffer. Sometimes I end up finishing a project in 10% of the expected time, but at least it's not over 100%?<p>I don't think that's very healthy for anyone involved though, it's better if for projects I can't estimate well we just do hourly so that I'm incentiviced to spend lots of time making it great and they're incentivized to give me more work in updating the spec without needing to renegotiate anything.<p>But yeah, I'd say yes estimate and do it in writing but keep it to yourself until you're actually good at it. It takes practice, but honest logs of your past projects will elucidate over time. Like how whenever my biologist coworkers would plan an 8 hour project, 11 hours in I'm just like... how did you not plan for cleanup and prep?<p>Some things are just not obvious right away, but can become clear in retrospectives that inform future estimates.
Reading the comments ( and the article ) I think people are forgetting about the customer causing problems.<p>For example, what do you do when you and your customer agree on certain features by a certain timeframe and then... that customer turns around and promises something to someone else, then asks you if you can do that _without_ _consulting_ _you_ _first?_<p>If you refuse, you cause trouble for your customer, and potentially yourself. And then there's cultural considerations. And then your customer gets distracted by this and that, and you lose control of you customer?<p>This kind of thing happens. Plenty of companies are square in the "customer is always right" camp, which I think is a _bad_ idea. The customer is not always right.<p>This is why I think planning and estimating is a good thing, but controlling your customer is also important to keep in mind. You have to be willing to compromise, yes, but you also need to say "no" sometimes, or at least say "Well, let's finish this first, get the product out the door, and put that in version 1.5".<p>However, I feel like a lot of people are too scared to do that.
Being pretty young and just getting used to making estimates, this was a wonderful read!<p>Having to guess how long a project will take is still very scary for me. Is there any way to get over the fear of others disagreing? I always feel like I'm about to embarrass myself by either estimating to high or to low...
One thing he misses out is that story points, eventually get turned into estimates using velocity. They are estimates, just a different approach based on past history.
This article misses the biggest reason estimates are important: to make decisions between projects and approaches. Prioritization function is impact/effort. If you have Approach A for which you estimate 10 person-weeks, and Approach B for which you estimate 50 person-weeks, you should pick Approach A.<p>Real time estimates, rather than abstract story points, are necessary to calibrate your future estimates, by measuring how over-optimistic you were with past projects.
I think estimates of effort required, estimates of timeline, and commitments to timeline (deadlines) are three different things with only loose relationships that are far too often conflated - to significant pain. I'm trying to play with this a bit in my personal process (and talking to my team about it) but don't really have any hard results yet.
If you can't ESTIMATE your software project, then you have no idea what you're doing.<p>An estimate is NOT A DATE, an estimate is a DURATION.<p>If you estimate 50hours and other things come up that eat into your time, you continually adjust the DATE, the duration shouldn't change. If you depend on an external sys and you estimate N hrs, but that system takes N+M hrs, then your duration date moves forward M hrs.<p>If there were unknowns, risks, as you uncover them, you move the date and if you communicated the unknowns and risks, then you can adjust the duration by adding the new info.<p>Ideally what you wish to do is eliminate all the unknowns and risk by NOT doing them. You're doing DEVELOPMENT not RESEARCH. Development is simply pulling in all your prior knowledge on how to solve problems and tacking similar or new problems.<p>Don't mix your R&D.
I’ve worked at a company that took this too far and product managers used the release cycle clock to game the system by launching features that were not even half-baked but just outright didn’t work but since they hit their official target of launching managed they to get promoted and the next person in line is responsible for fixing the problem. Instead of using the release cycle as a way to focus the product process it became a goal in itself. But this author seems to work with really top class people so maybe that level of stupidity in using the metric as the goal in itself is less of an issue in those circles
I am glad it works for you but I am not comfortable or confident doing this, unless i have a really firm grasp on the technology and that is the exception rather than the norm, these days. Estimations tend to be driven by customer expectations rather than technical limitations. If i estimate too high I look bad. Even if that is based on previous experience. If i don't deliver in the hoped-for-timeframe i might get fired. catch-22. Much better to not do it at all, if the business allows it (if it doesn't then it's still important to make keep hammering on estimation psychology ).
> 100 plus people to port Skype in 16 months.<p>To all employers out there: if you put me on a project with a hundred others to port a wee VOIP front-end to another platform, I too can get it done in a year and a half.
The article seems contradictory. Is it really estimating if you drop features you can't finish to ship by a deadline? Is a 16 month estimate worthwhile when you screw around for 12 months before getting serious and then getting it done? If the upshot is just to keep a conversation going with stakeholders and always be working on the most important functionality, isn't this mostly accomplished by 2 week sprints with a touch of externally set deadline pressure (e.g., WWDC)?
> Why the sudden productivity change? We had a big deadline coming up, and there was no option of not shipping. Suddenly, the whole team became focused, distractions were all gone, and we moved at a faster pace than I've ever felt the team do so.<p>Uh, what? Sounds like at the end of the day you ended up busting your ass trying to meet some incorrect estimate. I was hoping to hear something about how making better estimates made your life better and didn't happen.
The advice to not give estimates is just to work around engineers bad soft skills. So if you have engineers who can keep a healthy relationship with stakeholders then estimates are not a problem, but if you have typical engineers then someone else will have to do the estimates for the engineers without consulting them. Ultimately someone has to do the estimates so if the engineers can't handle it someone else will be forced to.
I thought I would hate this article, having years of delivering software with and without estimates, and preferring the latter. But it makes a compelling case!
The problem is is that most businesses refuse to negotiate on scope once deadlines have been agreed.<p>Getting a manger who is willing to do that is great.
The problem isn't estimates per se but how estimates are used:<p>1. A commitment that can't change<p>2. Manipulated to pressure people into work unreasonable hours<p>3. If something will take "too long", estimates will conflate level of effort with duration and be used, again, to manipulate people into doing unreasonable things<p>4. Used to cover up a failure to manage projects well
Do it if you want but in all my years I've never seen a company sunk by a missed deadline. At best it's a minor set back. At worst checks get delayed or contracts terminated. Maybe that's enough to sink your tiny startup when you're first starting out. For most companies that have made it past their first year it's not the end of the world.<p>Empirical studies on the causes of errors, delays, etc in software projects of different stripes and knowledge work in general suggest that <i>stress</i> and <i>sleep</i> are the most important factors [0]. In video games deadlines are paramount and yet, ironically, <i>crunch</i> as the systemic form of over-work has become known correlates strongly with review scores and sales: the more a team is forced into meeting these arbitrary deadlines the lower the review scores and overall sales of the game [1]. I don't think this is unique to the games industry. I've seen enterprise development shops put in crunch time to meet customer driven deadlines agreed to by the sales teams with similar results: developers burn out and leave the company, tech debt runs rampant, and customers get frustrated.<p>The article doesn't touch on the different kinds of projects one may be asked to give estimates for.<p>A speculative project shouldn't be estimated. This is where the team doesn't have the skills required or has never shipped any software with a similar scope or feature set. There are so many unknowns between where you are and the end goal that an estimate is only a dangerous guess. The only way you can make an accurate estimate is to begin work and get close to the goal. Some where between starting and finishing you will have enough information to make an informed and reasonably confident estimate. Along with good release planning this can be a relatively low-stress process. Estimates at the beginning of the project create poor expectations and can lead to stress.<p>The enemy of a good plan is a perfect one.<p>Stress is so bad that it won't matter, much, that you do code review or have automated CI and CD gates and checks. Your engineering team will simply not be as effective as a team that isn't stressed or tired. Anything you can do to keep your team from being stressed out or tired is going to translate into better outcomes. If that means relaxing on deadlines and focus more on results and progress than do that instead.<p>One thing I can agree with is that communication is key. And a good night's sleep.<p>[0] <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2656292/" rel="nofollow">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2656292/</a><p>[1] <a href="https://gamasutra.com/blogs/PaulTozour/20150120/234443/The_Game_Outcomes_Project_Part_4_Crunch_Makes_Games_Worse.php" rel="nofollow">https://gamasutra.com/blogs/PaulTozour/20150120/234443/The_G...</a>