9 ms·

Stop wasting time getting estimates right

140 points by jakobloekke 12y ago

dpweb 12y ago
At work, we are constantly hounded by non-technical business people for estimates. They want to time/cost box you. To them - you're an expense, and an expensive one. My analogy would be someone asking how long it will take me to drive to my kids' school to pick them up. 70% of the time there is no traffic and takes 35 minutes. 25% of the time there is some wreck and takes 50-60 minutes. 5% of the time there is bad weather and very bad traffic and takes 60-80 minutes. So, in your mind - most of the time it takes 35 minutes, and often the devs' answer is "35 minutes". This is where the experience comes in. The correct answer is.. 80 minutes. I tend to accompy this (to the particularly ignorant non-technical manager) with various disclaimers about the 40+ year ongoing issue in est. sw development.
- omouse 12y ago
  That's the biggest danger with estimates, that you're being held accountable for a padded guesstimate. One way of avoiding this is to give estimates in ranges or with +/- attached: "It will take 2 days, + 5 days, - 1 day" <-- that shows a lot of risk "It will take 1-2 hours, + 3 hours - 0.5 hours" <-- again, showing that there's some risk Or you push back and tell them to give you some time to form a better estimate or that you will give them an estimate update as soon as you know more. The issue is that most software developers are not trained in how to estimate and in how to deal with these time/cost boxing scenarios. We don't attend a class like managers do on how to deal with situations like this. We have to learn as we go along. I highly recommend Steve McConnell's Rapid Software Development, fantastic book, it has a chapter on estimation and how to deal with client's and boss's that ask for estimates.
  - sime 12y ago
    He also has a whole book on estimation called Software Estimation: Demystifying the Black Art. It's a great read as well.
    - omouse 12y ago
      Bought it and recommended it to someone already, thanks for the suggestion!
  - blt 12y ago
    In my opinion, if someone is asking you for estimates on 1-2 hour tasks, that person should kindly remove him/herself from the software development industry.
    - gknoy 12y ago
      You could simply say, "I don't give estimates in under 3-hour increments, because there are inevitably other fire-extinguishing and support activities that interrupt even the most trivial tasks." Sometimes I get interrupted with "Alice needs X added to Y right away", or "Bob needs reassurance that this is working as intended in the original ticket" -- no problem. Other times, one might lose productivity to things like, "Java update broke our GWT compilation toolchain completely". It helps if your manager knows that such interruptions happen, too. I also am a fan of overbudgeting and then revising later once I understand the problem better.
- geon 12y ago
  This happens when people confuse estimates with deadlines. I've had clients trying to negotiate my estimate downwards. So stupid. Why would you want to underestimate the actual needed time? You want to go over budget?
  - Dystopian 12y ago
    They want to negotiate your estimate down, so they can then pin your quote and budget to the lowered estimate. "Going over budget? That's fine, let's renegotiate. Remember though that you're already behind on this project so that needs to be taken into account. We'd prefer this last leg of the project to be flat rate..." It's definitely not right - and as a contractor your should read the tarot cards and have had preparations in place so it wouldn't happen - but you'd be amazed at how often variations of this scheme work out with PMs and procurement at larger companies that should really know better.
    - geon 12y ago
      In this case, they were billed by the hour anyway, so no.
- scotty79 12y ago
  > At work, we are constantly hounded by non-technical business people for estimates. They actually want you to tell them price. They just think that price is called estimate in IT world. I try to clarify on each occasion that what I'm giving them is not a price, not even an actual estimate. I'm giving them just my guess about the future. To get an estimate they need to apply some math to my guess, hopefully based on project history and other factors. Full price will never be known because all actions bring in complexity into the system, that causes technical debt to grow by unknown amount.
omouse 12y ago
I've changed my mind on estimates; if you're giving a guesstimate it's your professional responsibility to make it clear that this is a guess and to explain that as you work or investigate the task(s) you will have a better estimate. If you're estimating once at the beginning of a sprint and neglecting to update the estimate as you're working on the task or as you have new information on the task, you are being unprofessional. It's the finer-grained equivalent of your project manager or account manager failing to tell the client or the boss that the project will take longer than expected after re-evaluating risks. At my current job, the CTO is asking for estimates in order to get a project under control. The first estimates at the beginning of our sprints are not fine-grained but as I work on a task I add more information and update the estimate based on what I know. Sometimes the second and third estimate will be a guess as well but at that point there will be some code written (or read/investigated) which makes it easier to do an estimate. Padding estimates is something that I'm against when you have enough information about the task. If you're padding to account for things like meetings or interruptions, don't do it, just log how much those are taking and make a note of it and then everyone can see that your estimates are correct (it did take you 5 minutes to do task XYZ) and that meetings and bullshit interruptions are eating up lots of time. A daily standup that takes 30 minutes and then 1hr lunch and a 30min team meeting should be logged against the project but shouldn't affect your estimate of the task. I think the issue is that the estimate can be seen, by managers and developers, as the end goal for the task. If you estimate at 2 hrs and you finish in 1 hr you can just get on Hacker News or reddit for an hour. If you estimate 0.5 hrs and it takes 10 hrs, you shouldn't be penalized as if you're late. Updating task estimates as you gain more information about them gets rid of that issue. If you think that 2 hr estimate was too optimistic, go ahead and update your estimate. You can't be held accountable for a guesstimate, you can only be held accountable for the failure or success of doing the task itself. If you don't know how long will it take, make it clear to your team, boss or client that this is the case and that you will need some time to research and to estimate. If there's a lot of tasks that need to be done, estimating might take half a day or a day as you go through everything. That estimation work needs to happen for any project that has its deadlines already defined (this is frequently the case and why agile can't be improperly implemented in most workplaces). Management needs to give you time so that you can do the professional tasks that need to be done. You can't fix what you can't measure and as time goes on your estimation skills will get better.
tragomaskhalos 12y ago
We are in a situation where the client wants some enhancements, we know to an order of magnitude how hard they are - ie more than a few days, less than a month - but cannot be more accurate without actually diving in and basically doing the work itself. But they will not green light us without an estimate. Result = deadlock. I dream of a world where (a) customers understand that this is an art, not bricklaying, and (b) realise that always demanding a number up front is just going to cost them more money because the s/w folks will always highball it to cover themselves for unexpected issues.
- dustingetz 12y ago
  I think it's widely understood that product teams write higher quality software than consulting teams
  - jakejake 12y ago
    I would say that is probably true but isn't exactly fair to the individual developers on those teams. Product teams tend to be stable, were hired for their domain expertise, and have been working on the same product for a long time. So naturally they are a well-oiled machine for producing one specific product. Consultants are a mix of whoever is available at the time. They may or may not have any previous domain experience. Each programmer might be working on multiple projects of totally different companies at the same time. Developers might get rotated in/out of projects mid-way. So it's not that consultants are crappy developers and product teams are excellent developers, it's more the situation that they're thrown in.
  - tragomaskhalos 12y ago
    Sorry if I'm being dense, but how does that relate to what I wrote above?
    - dustingetz 12y ago
      I guess I was alluding that if one is in a consulting situation where he can no longer estimate, one possible solution may be to increase quality by being more like a product team, and the resulting clarity of thought will help out his estimates
zobzu 12y ago
id like if all my stuff took 100x1min as in the author story ;)
kikki 12y ago
Unrelated: the first heading should be "preface" not "prefase" :)
ukigumo 12y ago
I liked this article but I couldn't stop thinking "you would do well in investing in a project manager" at every bullet point.
- conradfr 12y ago
  Are you supposed to have a project manager in a lean or agile ? No, you're a self-reliable and democratic driven team with a PO as a single point of contact, with no hierarchy that will mess up this beautiful utopia.
  - ukigumo 12y ago
    Exactly! No architecture, no structure, no process, no documentation and with some luck, no money either.
fxn 12y ago
I have been doing freelancing for the last 5 years without estimations or deadlines. Has worked so great, everyone involved is focused on the task, you iterate and concentrate on business value, quality of the solution, etc. Nothing can be "late", there is no "I said that by X..." in your subconscious (because you like to do what you say in the end), no absurd negotiations or revisions, there is nothing to try to stick to, nothing artificial interfering with working hard to get the best out of the project or task at hand. I wholeheartedly recommend it to anyone who can work that way.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- c1sc0 12y ago
  Can you elaborate a bit more? What types of projects do you do? Where do you find these types of clients?
  - fxn 12y ago
    In practice, this starts with my availability. Since I don't work with estimations my gigs do not have an estimated end date, because what I only care is that what I am hired for finishes in its natural way. In particular I don't tell my clients "I need to be done by time T", that would be putting a de facto deadline to the project and wouldn't be consistent with my view to focus on bringing the best value to what I am hired for. So this is not a selling strategy, but it is just the natural way in which the conversation normally goes. Then, I explain why I work that way. Also, the corollary is that if that person or company hires me, I will be as focused on their problem and in the quality of work as I am being now with my current gig (the commitment that doesn't allow me to give a starting date.) I have some public track record, so when someone hires me they know who are hiring. That, I am sure, also helps. Though I have to say when I started I didn't have so much exposure. BTW, that for me includes Scrum sprints. No matter if you call it points, or whatever, you are estimating that something is going to take so much, and that by next week we could deliver A, B, and C. Is the same shit in the end. Don't do that, talk about facts. Use past tense. Last week we DID A, B, and C. This project COSTED this much. Some clients already work without that shit, pipeline and priorities. That's all. Also, do not put yourself in a compromise by inertia. "I'll have it by tomorrow" and nobody asked. Try to avoid that kind of sentences. Then you absolutely have to do it by tomorrow no matter what, or else you need to excuse to fail the expectation. Be deliberately vague: "I'll have it soon", "I'll write back", "I'll prioritize this", often times that language is more than enough for communicating. But best of all: say nothing! Just work hard, let your work speak for you. Working hard is key. Work hard and communicate often to have a close feedback loop. If you do that, in a few days your client already sees how it goes, it can feel the speed (as you do), it can feel the velocity, and that everyone is concentrated on what matters for quality. If you enter that flow, everything is so smooth and good for the success of the project. I have been working non-stop that way for 5 years, and I truly believe it is the best way to deliver quality software.
lmm 12y ago
Simpler estimates are a step in the right direction, but this article is still advocating a very heavyweight (dare I say unagile?) process. Time-tracking by individual story card? What would you even do with that data if you had it? Sure you can put a precise numerical cost on how much a "medium" story usually takes - but your estimates of feature value are never going to be accurate enough that the difference between $6000 and $5900 is a yes-no decision. Going back to the points actually saves you time here - and saves you a lot of less tangible value by avoiding timesheets (when employers introduce timesheets, I leave. How much does hiring a new dev cost?). We got 59 points of stories done last iteration, therefore cards cost $TOTAL_TEAM_COST/59 per point. Done.
- ebiester 12y ago
  The next step is to break all stories down to similarly sized stories. Sometimes it is difficult but I have seen teams who can get it consistently and have high confidence intervals in their times.
ThomPete 12y ago
I have said it before but I think it bears repeating. Time estimations is an industrial way of thinking applied to a post-industrial world. In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X) In the post industrial world every project is about problem solving and scoping. To put it into comparison. If we apply post-industrial thinking to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed. It will take many many years before time estimation will die, but it will happen.
- thirdtruck 12y ago
  [Edit: Story changed based on feedback below.] Here's my analogy: "Developer, how long will it take to acquire a vehicle that can travel a mile?" "That depends. Will the vehicle drive over a highway, through the sky, or dig through a mountain?" "That's only an implementation detail, right? Give me a ballpark estimate." "I can call a taxi here in 15 minutes and $50. Chartering an airplane will require two days and $2000. A granite-boring drill will take 6 months to design, 2 years to build, and several million dollars, possibly several times that if --" "Geeze, no wonder no one trusts developer estimates. I'll double it and tell them half an hour and $100, just to be safe."
  - ThomPete 12y ago
    Thats still a kind of industrial example IMO, the issue with post-industrial is different. Its fairly easy to estimate how long it's going to travel a mile once you undstand how you have to travel it. You can rarely go faster than you have estimated. No the actual problem is that in the post-industrial world you haven't even build the car to travel by the highway or the tools to go through the mountain.
    - thirdtruck 12y ago
      Good point. I'll update the story to better reflect that.
DanielBMarkham 12y ago
Estimate frequently, quickly, and move on to execution. This will allow you real-world information to make a better estimate next time. Lots of little fuzzy guesses which trend in the right direction. I believe the complaint about "not getting any closer to resolution" is a red herring. The value in the exercise is creating a shared mental model, not creating COCMO VII. There is no perfect estimation model, mainly because your team is not full of robots. We screw up when we get up from the IDE and start thinking of technology development in the same way as we would using the Jquery framework. People do not work like machines.
ArturT 12y ago
We recently had a discussion with a client about estimation. From the developer point of view it's hard to predict the date because of many things which might happen during development and we are not aware yet about them at the moment when we need to declare the date. Now we are using historical data to predict how many calendar days the features scope may take with a specific confidence level. From the client perspective dates are important because they need to coordinate release of multiple projects and dates help them release right stuff, in right order, in right moment on production. Here is article about our approach http://blog.lunarlogic.io/2015/project-management-estimation/ http://blog.lunarlogic.io/2015/project-management-estimation...
deleted 12y ago
[deleted]
jacques_chester 12y ago
The title says "Stop wasting time getting estimates right", then outlines a number of classic ways in which estimates can be improved: give a range, collect data, break down estimates (which is problematic by the way[0]). The process described actually sounds a lot like the Personal Software Process that Watts Humphrey described in the 1990s, right down to the use of proxy values for estimation purposes. [0] obligatory self-promoting link -- http://confidest.com/articles/how-accurate-was-that-estimate/ http://confidest.com/articles/how-accurate-was-that-estimate...
deleted 12y ago
[deleted]
coldcode 12y ago
The quality of estimates improves directly in relation to the completion date of the project. Like forecasting the weather - looking out the window always beats the forecast for the next week.
- jeremiep 12y ago
  I've seen the opposite happens, the closer to the deadline the worse the estimates. At which point the entire team is in constant crunch mode and getting tired. This causes even more defects, which cause even worse estimates... One project I worked on last year saw four different authentication systems implemented. The last one was built on the leftovers of the scaffoldings of the previous three. We couldn't get rid of it because many other systems had been tightly integrated into authentication at various points in time. I would say the quality of the estimates aren't a function of the project's completion but instead a function of the quality and simplicity of the codebase.
jakobloekke 12y ago
I want to point out, that I'm not the author of this article. It was written by a former colleague of mine who is a very talented project manager.
revmoo 12y ago
This shit is fucking retarded.
bane 12y ago
The whole game around estimates are a dirty way of dealing with other issues: 1) Can this be done before we run out of money and market opportunity? 2) How should other assets in the company be coordinated around the product. e.g. marketing needs a lead time to produce their campaign. 3) Scopeboxing. For #1: If you work in a big-corp, this is tied explicitly to some project budget you have to manage. Going over that budget is a no-no. For startups, it's the investment dollars in the company. Startups tend to be over-capitalized for the products they tend to produce. Big-cos tend to under-fund in an attempt to capture as much of the money as profit (especially if your big-co is a contractor of some sort). Estimates are intended to be converted into budget dollars (time * team-size * burn-rate) and are critically important signalling mechanisms. No money, no work. For #2: Development is not the only piece of the puzzle. There might be a team just as large and much more expensive that relies on your estimate to get their work done so that the company runs in a reasonably coordinated fashion. "It'll get done when it gets done" doesn't allow anybody else in the universe to plan anything at all, and now the company has a bunch of expensive resources sitting around doing nothing until the primadona development team produces something. This is usually the source of adversarial and caustic inter-departmental relationships in a company. For #3: Good development managers learn to invert the question of estimates. When asked "how long will this take to get done?" they answer with "how much time do we have? we can get this much done in that time" and then make that scope a commitment. This provides much more valuable information to corporate management, they get to set their schedule, but they also get to understand what the product they're going to be delivering is going to look like, which informs the teams from #2. It also defines a clear barrier of what will be delivered and when. Scope creep gets cleanly pushed into "the next development phase" because anything that wasn't promised and agreed upon is outside of the current development phase. This approach lets the development manager set expectations, and also lets them never say "no". "Sure we can do that, I'll put that in the next development phase" becomes the answer. Phases should be scoped to deliver a completed working version of the product (as opposed to sprints which complete components of a product). If the budget runs out, or a marketing campaign is underway and development is paused, the development manager now has a barrel full of things to scope out for the next development phase. Taking this time to work with corporate management and prioritize and scope out the next phase is usually a good idea. When the time comes to resume work, the development manager can again say "I'll deliver this much by this date". Awesome development managers will underpromise on the scope and keep a reserve of features as a stretch goal. If they hit the major scope, they look like a competent and solid development team. If they hit the stretch goals they surprise and delight everybody else in the company. I'm not saying it's easy, but it's better than a waterfall approach and what passes as Agile in most shops. It results in shipping products and allows development to be better determined into overall strategy. What corp management needs is predictability, not undetermined development cycles and feature creep. (#4) - To be able to say "how much time do we have? we can get this much done in that time" the devmanager needs to actually know how to estimate. A good technique is to break the tasks down and ask the developer who's likely to do the coding how long they'd take, add up those times and see if they fit by the due date. If not, start tossing things. It's amazing how much you can cut from a product and still end up with an MVP or with another version phase. (#5) - To do all this also requires the devmanager to understand what are the minimum tasks required to achieve a working product at the end of a phase. Those tasks are the core of the scope. Anything else is stretch. This usually means the devmanager needs to have a bit of domain expertise to figure this out. It should come as a surprise, just like soda execs shouldn't run Apple, devmanagers who don't understand what they're building shouldn't be building it.
dkrich 12y ago
The problem I've seen with estimates is a mix of an inconsistency of ability mixed with a lack of experience in what is being done. For example, I know that I can build a basic CMS system in Rails in a day because I've done it 100,000 times. The details of the text, layout, etc. don't take much more time to develop, so if the requirements are some derivative of that functionality I can give a pretty accurate estimate for how long it will take to build. However once team size and project scope expands, you have Developer A who is great at the assigned tasks and can finish a deliverable scoped at two weeks in two afternoons. Meanwhile, you have Developer B who is not so great at the assigned tasks, and requires a lot of hand-holding and assistance to build a below-par version of what the client expects. This mixture leads to ridiculously inaccurate estimates. What it usually boils down to on these projects is a spreadsheet written by an out-of-touch project manager who has to answer to a senior manager and pulls a timeframe out of thin air. A lot of planning and documenting goes into filling about 2/3 of this timeframe, and then the last 1/3 is spent killing yourself trying to finish a shitload of work in a short time frame to meet the original estimate so that the PM can show that he's really good at estimates! I've been through this process so many times and think about it constantly and have come to the conclusion that it's done this way because quite simply, there is no better way that accounts for the client's demand to have a firm estimate in place.
- jakejake 12y ago
  I agree. I find the thinking of developers here is all over the place due to the variety of types of work we're all doing. But some people take a hard-line approach to estimates based on the recommendation of others who are working in a totally different environment. If you are in the consulting business and you refuse to give estimates, then you simply will miss out on a huge amount of opportunities. That's just reality. No amount of explaining your methodology is going to get you a large corporate contact if you can't provide a quote. If you have no interest in that type of work, then that's fine, but there are plenty of people who do make their living that way. If you are on a product team, you may have an understanding business who realize the nature of programming. But you still have to work with the company so that press releases, support documentation, marketing, etc can get done. The sales and support teams may need training on features. So there is some degree of estimations that are still needed. As far as other types of ground-breaking experimental research programming - I can't really speak on that subject as far as deadlines because I've never done that.
jakejake 12y ago
This is an interesting article to me as I'm currently making a series of screenshot videos to document a project that we're doing at my company. It is estimated at about 3 months and I'm recording the progress and everything to see if we hit our goals. I thought it would be fun to post them as we go, but for competitive reasons I'm going to hold off until we actually get it done and then post them all. The videos so far are turning out to be somewhat long (10 minutes reviewing each week of the project) so I'm wondering if anybody will actually care about viewing such a thing?
alkonaut 12y ago
Estimates will always suck for 10 of them, but they work for large numbers (you can tweak the knobs to compensate for bad estimates). My experience after around 5000 stories and 100 man years (single project) is that we are slowly approaching acceptable accuracy!
andyhoff 12y ago
#NoEstimates to me is often an indicator of poor company culture. It immediately makes me think of shops where there's a disconnect between developers and the rest of the organization. The business and product people are unable to explain why they need estimates. Often they don't know it themselves and are just passing on the request from their bosses or customers. They hold devs accountable for estimates even if the requirements, priorities and teams change. They also think estimating is free - they don't realise that producing meaningful estimates takes time and requires a deep understanding of the code base. It also requires clear, precise requirements which they are unable to provide. Developers at these shops believe their single responsibility is producing elegant code. They don't have to prioritise features based on their cost and value; and they don't have to communicate with clients, investors or sponsors. Many devs never learned estimating, that's why they call it an "art". They spend forever to produce estimates that turn out to be way off, even if requirements and circumstances don't change. The lazy way out is to say: Estimating is a waste of time because estimates are almost always wrong. I have seen estimating done right: It took about 5%-10% of the overall effort spent. It helped make or break business cases, prioritise features and manage client expecations. It raised questions that, if left unanswered, could have resulted in massive cost explosions and unhappy customers later on. Key cultural ingredients: - Business and product people don't live on an island. They understand that estimating is neither free nor instant. They work close enough with developers to know what level of detail is necessary and they also understand the value of refactoring, test automation, pair programming, etc. - Developers don't live on an island. They are involved in product decisions and client communication, so they understand why people are asking for estimates. They not only take pride in the quality of their code but also in their ability to deliver features quickly - Estimates are not used to crucify developers, but the company culture allows an open and forward-looking conversation when the actual effort deviates a lot - Estimating is seen as a skill. Becoming good at it (ie. accurate and efficient) is a requirement to get senior dev roles - Everybody understands that when the world around them changes, the estimates change too Final note: work should be estimated in line with the predictability of the business. If your company is pivoting every 8 weeks then there's no use in estimating 6 months out. If you have a successful app for iOS and consider expanding to other platforms, it's probably worth estimating
- 12y ago
derriz 12y ago
Reasonable time cost estimation is certainly possible with software. It's not particularly easy but you certainly have a better chance if you at least expose yourself to the decades of hard research on the subject and not arrogantly imagine that everyone before you started programming of flogging your "agile approach" was an idiot and knew nothing about software development. Software estimating is not a particularly pleasant task - neither for developers (they generally have no training in the area and so don't even know how to approach the problem) nor managers (who have too little technical knowledge). And since 95% of development is writing in-house CRUD stuff or putting together lightly trafficked web-pages, it's tempting to bask in ignorance and pretend that not only is the task almost impossible anyway (and so pointless) but that in-fact it's unnecessary. And for IS department mickey-mouse projects, this is probably the case. Some of us however have had to pitch fixed price tenders for large software development projects, for example. And no, the customer isn't going to accept that it will be done when it's done and that we should just start a few sprints and see how it goes. And if you get the estimate wrong (too low), you screw yourself and lose money on the project - too high and you don't even get the contract. In this environment, you learn quickly that estimation is vital, difficult but possible with the appropriate effort. And yes I hated doing it the first time but it became almost satisfying after a few iterations having gained some confidence. This assumption that a "post-industrial", agile, folksy-anecdotal approach is appropriate for all software development really pisses me off. It breeds developer myopia, ignorance, self-importance and exceptionalism. Believe it or not, engineers have estimated, planned and executed very complex systems inside and outside of software. But it's only in software engineering do you find clowns earnestly claiming that estimating or planning developing some crappy CMS system is beyond human capabilities because software is so "different" and that estimating and planning a project like the Hoover dam was easy in comparison.
- napoleond 12y ago
  I agree that software estimating is absolutely possible and often necessary. However, it's important to keep in mind that software engineering has much less in common with the more traditional engineering disciplines than they have with each other. A big difference is the ability to heavily iterate on a design after it's been shipped (not in all cases, and within limits, but still generally much more than a structure or physical machine). So we often see procurement cycles which treat software development like a construction project or equipment manufacturing (because the organizations making the purchase--enterprise and government--have built their procurement processes around that sort of project) even though that cycle does not necessarily match the way software "should" be built. FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).
J_Boeg 12y ago
I wrote the essay and seems it sparked a good discussion in here :-) Can't comment on it all but the point I tried to get across was actually very closely related to the style of thinking most of you promote in here - focus on the outcome not the output, iterate fast and expect uncertainty in both cost and outcome. The principles I present is trying to do exactly that (IMO) while providing the structure to make informed decisions in terms of prioritization and risk. Basically - Make it short and simple for the team to estimate stuff so they can spend their time focusing on what's important (which is NOT worrying about whether 4 or 8 hours remain before you hit you original estimate and the stress, drop in motivation and even potential blame games that might follow from that) - and be disciplined enough about data to answer all the other questions people will ask anyway. Estimating in time sucks! And as I wrote, yes you can skip registering time on the individual user story if you find yourself in an environment where that is doable. You will loose a bit of data to make better informed decisions but I'll admit following the 80/20 rule that you probably should not do it if you can avoid it. Once the structure is set up it actually is quite lightweight (especially for the team but also the person collecting the data, both with and without the per user story time registration) and having at least some amount of real data does in my experience provide better and faster decisions in most contexts. But anyway, whether you agree or you don't thank you all for discussing and sharing. Never in a million years expected close to 13.000 users from 6 continents to visit my blog in less than 24 hours (and still rising) BR Jesper
dreamfactory2 12y ago
Or save yourself a lot of time by making each story worth 1 point and just count how many stories you have. They will average out over the course of a program (this is borne out by studies of many projects at Thoughtworks).

140 points by jakobloekke 12y ago

dpweb 12y ago

At work, we are constantly hounded by non-technical business people for estimates. They want to time/cost box you. To them - you're an expense, and an expensive one. My analogy would be someone asking how long it will take me to drive to my kids' school to pick them up. 70% of the time there is no traffic and takes 35 minutes. 25% of the time there is some wreck and takes 50-60 minutes. 5% of the time there is bad weather and very bad traffic and takes 60-80 minutes. So, in your mind - most of the time it takes 35 minutes, and often the devs' answer is "35 minutes". This is where the experience comes in. The correct answer is.. 80 minutes. I tend to accompy this (to the particularly ignorant non-technical manager) with various disclaimers about the 40+ year ongoing issue in est. sw development.

omouse 12y ago
That's the biggest danger with estimates, that you're being held accountable for a padded guesstimate. One way of avoiding this is to give estimates in ranges or with +/- attached: "It will take 2 days, + 5 days, - 1 day" <-- that shows a lot of risk "It will take 1-2 hours, + 3 hours - 0.5 hours" <-- again, showing that there's some risk Or you push back and tell them to give you some time to form a better estimate or that you will give them an estimate update as soon as you know more. The issue is that most software developers are not trained in how to estimate and in how to deal with these time/cost boxing scenarios. We don't attend a class like managers do on how to deal with situations like this. We have to learn as we go along. I highly recommend Steve McConnell's Rapid Software Development, fantastic book, it has a chapter on estimation and how to deal with client's and boss's that ask for estimates.
- sime 12y ago
  He also has a whole book on estimation called Software Estimation: Demystifying the Black Art. It's a great read as well.
  - omouse 12y ago
    Bought it and recommended it to someone already, thanks for the suggestion!
- blt 12y ago
  In my opinion, if someone is asking you for estimates on 1-2 hour tasks, that person should kindly remove him/herself from the software development industry.
  - gknoy 12y ago
    You could simply say, "I don't give estimates in under 3-hour increments, because there are inevitably other fire-extinguishing and support activities that interrupt even the most trivial tasks." Sometimes I get interrupted with "Alice needs X added to Y right away", or "Bob needs reassurance that this is working as intended in the original ticket" -- no problem. Other times, one might lose productivity to things like, "Java update broke our GWT compilation toolchain completely". It helps if your manager knows that such interruptions happen, too. I also am a fan of overbudgeting and then revising later once I understand the problem better.
geon 12y ago
This happens when people confuse estimates with deadlines. I've had clients trying to negotiate my estimate downwards. So stupid. Why would you want to underestimate the actual needed time? You want to go over budget?
- Dystopian 12y ago
  They want to negotiate your estimate down, so they can then pin your quote and budget to the lowered estimate. "Going over budget? That's fine, let's renegotiate. Remember though that you're already behind on this project so that needs to be taken into account. We'd prefer this last leg of the project to be flat rate..." It's definitely not right - and as a contractor your should read the tarot cards and have had preparations in place so it wouldn't happen - but you'd be amazed at how often variations of this scheme work out with PMs and procurement at larger companies that should really know better.
  - geon 12y ago
    In this case, they were billed by the hour anyway, so no.
scotty79 12y ago
> At work, we are constantly hounded by non-technical business people for estimates. They actually want you to tell them price. They just think that price is called estimate in IT world. I try to clarify on each occasion that what I'm giving them is not a price, not even an actual estimate. I'm giving them just my guess about the future. To get an estimate they need to apply some math to my guess, hopefully based on project history and other factors. Full price will never be known because all actions bring in complexity into the system, that causes technical debt to grow by unknown amount.

omouse 12y ago

I've changed my mind on estimates; if you're giving a guesstimate it's your professional responsibility to make it clear that this is a guess and to explain that as you work or investigate the task(s) you will have a better estimate. If you're estimating once at the beginning of a sprint and neglecting to update the estimate as you're working on the task or as you have new information on the task, you are being unprofessional. It's the finer-grained equivalent of your project manager or account manager failing to tell the client or the boss that the project will take longer than expected after re-evaluating risks. At my current job, the CTO is asking for estimates in order to get a project under control. The first estimates at the beginning of our sprints are not fine-grained but as I work on a task I add more information and update the estimate based on what I know. Sometimes the second and third estimate will be a guess as well but at that point there will be some code written (or read/investigated) which makes it easier to do an estimate. Padding estimates is something that I'm against when you have enough information about the task. If you're padding to account for things like meetings or interruptions, don't do it, just log how much those are taking and make a note of it and then everyone can see that your estimates are correct (it did take you 5 minutes to do task XYZ) and that meetings and bullshit interruptions are eating up lots of time. A daily standup that takes 30 minutes and then 1hr lunch and a 30min team meeting should be logged against the project but shouldn't affect your estimate of the task. I think the issue is that the estimate can be seen, by managers and developers, as the end goal for the task. If you estimate at 2 hrs and you finish in 1 hr you can just get on Hacker News or reddit for an hour. If you estimate 0.5 hrs and it takes 10 hrs, you shouldn't be penalized as if you're late. Updating task estimates as you gain more information about them gets rid of that issue. If you think that 2 hr estimate was too optimistic, go ahead and update your estimate. You can't be held accountable for a guesstimate, you can only be held accountable for the failure or success of doing the task itself. If you don't know how long will it take, make it clear to your team, boss or client that this is the case and that you will need some time to research and to estimate. If there's a lot of tasks that need to be done, estimating might take half a day or a day as you go through everything. That estimation work needs to happen for any project that has its deadlines already defined (this is frequently the case and why agile can't be improperly implemented in most workplaces). Management needs to give you time so that you can do the professional tasks that need to be done. You can't fix what you can't measure and as time goes on your estimation skills will get better.

tragomaskhalos 12y ago

We are in a situation where the client wants some enhancements, we know to an order of magnitude how hard they are - ie more than a few days, less than a month - but cannot be more accurate without actually diving in and basically doing the work itself. But they will not green light us without an estimate. Result = deadlock. I dream of a world where (a) customers understand that this is an art, not bricklaying, and (b) realise that always demanding a number up front is just going to cost them more money because the s/w folks will always highball it to cover themselves for unexpected issues.

dustingetz 12y ago
I think it's widely understood that product teams write higher quality software than consulting teams
- jakejake 12y ago
  I would say that is probably true but isn't exactly fair to the individual developers on those teams. Product teams tend to be stable, were hired for their domain expertise, and have been working on the same product for a long time. So naturally they are a well-oiled machine for producing one specific product. Consultants are a mix of whoever is available at the time. They may or may not have any previous domain experience. Each programmer might be working on multiple projects of totally different companies at the same time. Developers might get rotated in/out of projects mid-way. So it's not that consultants are crappy developers and product teams are excellent developers, it's more the situation that they're thrown in.
- tragomaskhalos 12y ago
  Sorry if I'm being dense, but how does that relate to what I wrote above?
  - dustingetz 12y ago
    I guess I was alluding that if one is in a consulting situation where he can no longer estimate, one possible solution may be to increase quality by being more like a product team, and the resulting clarity of thought will help out his estimates

zobzu 12y ago

id like if all my stuff took 100x1min as in the author story ;)

kikki 12y ago

Unrelated: the first heading should be "preface" not "prefase" :)

ukigumo 12y ago

I liked this article but I couldn't stop thinking "you would do well in investing in a project manager" at every bullet point.

conradfr 12y ago
Are you supposed to have a project manager in a lean or agile ? No, you're a self-reliable and democratic driven team with a PO as a single point of contact, with no hierarchy that will mess up this beautiful utopia.
- ukigumo 12y ago
  Exactly! No architecture, no structure, no process, no documentation and with some luck, no money either.

fxn 12y ago

I have been doing freelancing for the last 5 years without estimations or deadlines. Has worked so great, everyone involved is focused on the task, you iterate and concentrate on business value, quality of the solution, etc. Nothing can be "late", there is no "I said that by X..." in your subconscious (because you like to do what you say in the end), no absurd negotiations or revisions, there is nothing to try to stick to, nothing artificial interfering with working hard to get the best out of the project or task at hand. I wholeheartedly recommend it to anyone who can work that way.

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
c1sc0 12y ago
Can you elaborate a bit more? What types of projects do you do? Where do you find these types of clients?
- fxn 12y ago
  In practice, this starts with my availability. Since I don't work with estimations my gigs do not have an estimated end date, because what I only care is that what I am hired for finishes in its natural way. In particular I don't tell my clients "I need to be done by time T", that would be putting a de facto deadline to the project and wouldn't be consistent with my view to focus on bringing the best value to what I am hired for. So this is not a selling strategy, but it is just the natural way in which the conversation normally goes. Then, I explain why I work that way. Also, the corollary is that if that person or company hires me, I will be as focused on their problem and in the quality of work as I am being now with my current gig (the commitment that doesn't allow me to give a starting date.) I have some public track record, so when someone hires me they know who are hiring. That, I am sure, also helps. Though I have to say when I started I didn't have so much exposure. BTW, that for me includes Scrum sprints. No matter if you call it points, or whatever, you are estimating that something is going to take so much, and that by next week we could deliver A, B, and C. Is the same shit in the end. Don't do that, talk about facts. Use past tense. Last week we DID A, B, and C. This project COSTED this much. Some clients already work without that shit, pipeline and priorities. That's all. Also, do not put yourself in a compromise by inertia. "I'll have it by tomorrow" and nobody asked. Try to avoid that kind of sentences. Then you absolutely have to do it by tomorrow no matter what, or else you need to excuse to fail the expectation. Be deliberately vague: "I'll have it soon", "I'll write back", "I'll prioritize this", often times that language is more than enough for communicating. But best of all: say nothing! Just work hard, let your work speak for you. Working hard is key. Work hard and communicate often to have a close feedback loop. If you do that, in a few days your client already sees how it goes, it can feel the speed (as you do), it can feel the velocity, and that everyone is concentrated on what matters for quality. If you enter that flow, everything is so smooth and good for the success of the project. I have been working non-stop that way for 5 years, and I truly believe it is the best way to deliver quality software.

lmm 12y ago

Simpler estimates are a step in the right direction, but this article is still advocating a very heavyweight (dare I say unagile?) process. Time-tracking by individual story card? What would you even do with that data if you had it? Sure you can put a precise numerical cost on how much a "medium" story usually takes - but your estimates of feature value are never going to be accurate enough that the difference between $6000 and $5900 is a yes-no decision. Going back to the points actually saves you time here - and saves you a lot of less tangible value by avoiding timesheets (when employers introduce timesheets, I leave. How much does hiring a new dev cost?). We got 59 points of stories done last iteration, therefore cards cost $TOTAL_TEAM_COST/59 per point. Done.

ebiester 12y ago
The next step is to break all stories down to similarly sized stories. Sometimes it is difficult but I have seen teams who can get it consistently and have high confidence intervals in their times.

ThomPete 12y ago

I have said it before but I think it bears repeating. Time estimations is an industrial way of thinking applied to a post-industrial world. In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X) In the post industrial world every project is about problem solving and scoping. To put it into comparison. If we apply post-industrial thinking to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed. It will take many many years before time estimation will die, but it will happen.

thirdtruck 12y ago
[Edit: Story changed based on feedback below.] Here's my analogy: "Developer, how long will it take to acquire a vehicle that can travel a mile?" "That depends. Will the vehicle drive over a highway, through the sky, or dig through a mountain?" "That's only an implementation detail, right? Give me a ballpark estimate." "I can call a taxi here in 15 minutes and $50. Chartering an airplane will require two days and $2000. A granite-boring drill will take 6 months to design, 2 years to build, and several million dollars, possibly several times that if --" "Geeze, no wonder no one trusts developer estimates. I'll double it and tell them half an hour and $100, just to be safe."
- ThomPete 12y ago
  Thats still a kind of industrial example IMO, the issue with post-industrial is different. Its fairly easy to estimate how long it's going to travel a mile once you undstand how you have to travel it. You can rarely go faster than you have estimated. No the actual problem is that in the post-industrial world you haven't even build the car to travel by the highway or the tools to go through the mountain.
  - thirdtruck 12y ago
    Good point. I'll update the story to better reflect that.

DanielBMarkham 12y ago

Estimate frequently, quickly, and move on to execution. This will allow you real-world information to make a better estimate next time. Lots of little fuzzy guesses which trend in the right direction. I believe the complaint about "not getting any closer to resolution" is a red herring. The value in the exercise is creating a shared mental model, not creating COCMO VII. There is no perfect estimation model, mainly because your team is not full of robots. We screw up when we get up from the IDE and start thinking of technology development in the same way as we would using the Jquery framework. People do not work like machines.

ArturT 12y ago

We recently had a discussion with a client about estimation. From the developer point of view it's hard to predict the date because of many things which might happen during development and we are not aware yet about them at the moment when we need to declare the date. Now we are using historical data to predict how many calendar days the features scope may take with a specific confidence level. From the client perspective dates are important because they need to coordinate release of multiple projects and dates help them release right stuff, in right order, in right moment on production. Here is article about our approach http://blog.lunarlogic.io/2015/project-management-estimation/ http://blog.lunarlogic.io/2015/project-management-estimation...

deleted 12y ago

[deleted]

jacques_chester 12y ago

The title says "Stop wasting time getting estimates right", then outlines a number of classic ways in which estimates can be improved: give a range, collect data, break down estimates (which is problematic by the way[0]). The process described actually sounds a lot like the Personal Software Process that Watts Humphrey described in the 1990s, right down to the use of proxy values for estimation purposes. [0] obligatory self-promoting link -- http://confidest.com/articles/how-accurate-was-that-estimate/ http://confidest.com/articles/how-accurate-was-that-estimate...

deleted 12y ago

[deleted]

coldcode 12y ago

The quality of estimates improves directly in relation to the completion date of the project. Like forecasting the weather - looking out the window always beats the forecast for the next week.

jeremiep 12y ago
I've seen the opposite happens, the closer to the deadline the worse the estimates. At which point the entire team is in constant crunch mode and getting tired. This causes even more defects, which cause even worse estimates... One project I worked on last year saw four different authentication systems implemented. The last one was built on the leftovers of the scaffoldings of the previous three. We couldn't get rid of it because many other systems had been tightly integrated into authentication at various points in time. I would say the quality of the estimates aren't a function of the project's completion but instead a function of the quality and simplicity of the codebase.

jakobloekke 12y ago

I want to point out, that I'm not the author of this article. It was written by a former colleague of mine who is a very talented project manager.

revmoo 12y ago

This shit is fucking retarded.

bane 12y ago

The whole game around estimates are a dirty way of dealing with other issues: 1) Can this be done before we run out of money and market opportunity? 2) How should other assets in the company be coordinated around the product. e.g. marketing needs a lead time to produce their campaign. 3) Scopeboxing. For #1: If you work in a big-corp, this is tied explicitly to some project budget you have to manage. Going over that budget is a no-no. For startups, it's the investment dollars in the company. Startups tend to be over-capitalized for the products they tend to produce. Big-cos tend to under-fund in an attempt to capture as much of the money as profit (especially if your big-co is a contractor of some sort). Estimates are intended to be converted into budget dollars (time * team-size * burn-rate) and are critically important signalling mechanisms. No money, no work. For #2: Development is not the only piece of the puzzle. There might be a team just as large and much more expensive that relies on your estimate to get their work done so that the company runs in a reasonably coordinated fashion. "It'll get done when it gets done" doesn't allow anybody else in the universe to plan anything at all, and now the company has a bunch of expensive resources sitting around doing nothing until the primadona development team produces something. This is usually the source of adversarial and caustic inter-departmental relationships in a company. For #3: Good development managers learn to invert the question of estimates. When asked "how long will this take to get done?" they answer with "how much time do we have? we can get this much done in that time" and then make that scope a commitment. This provides much more valuable information to corporate management, they get to set their schedule, but they also get to understand what the product they're going to be delivering is going to look like, which informs the teams from #2. It also defines a clear barrier of what will be delivered and when. Scope creep gets cleanly pushed into "the next development phase" because anything that wasn't promised and agreed upon is outside of the current development phase. This approach lets the development manager set expectations, and also lets them never say "no". "Sure we can do that, I'll put that in the next development phase" becomes the answer. Phases should be scoped to deliver a completed working version of the product (as opposed to sprints which complete components of a product). If the budget runs out, or a marketing campaign is underway and development is paused, the development manager now has a barrel full of things to scope out for the next development phase. Taking this time to work with corporate management and prioritize and scope out the next phase is usually a good idea. When the time comes to resume work, the development manager can again say "I'll deliver this much by this date". Awesome development managers will underpromise on the scope and keep a reserve of features as a stretch goal. If they hit the major scope, they look like a competent and solid development team. If they hit the stretch goals they surprise and delight everybody else in the company. I'm not saying it's easy, but it's better than a waterfall approach and what passes as Agile in most shops. It results in shipping products and allows development to be better determined into overall strategy. What corp management needs is predictability, not undetermined development cycles and feature creep. (#4) - To be able to say "how much time do we have? we can get this much done in that time" the devmanager needs to actually know how to estimate. A good technique is to break the tasks down and ask the developer who's likely to do the coding how long they'd take, add up those times and see if they fit by the due date. If not, start tossing things. It's amazing how much you can cut from a product and still end up with an MVP or with another version phase. (#5) - To do all this also requires the devmanager to understand what are the minimum tasks required to achieve a working product at the end of a phase. Those tasks are the core of the scope. Anything else is stretch. This usually means the devmanager needs to have a bit of domain expertise to figure this out. It should come as a surprise, just like soda execs shouldn't run Apple, devmanagers who don't understand what they're building shouldn't be building it.

dkrich 12y ago

The problem I've seen with estimates is a mix of an inconsistency of ability mixed with a lack of experience in what is being done. For example, I know that I can build a basic CMS system in Rails in a day because I've done it 100,000 times. The details of the text, layout, etc. don't take much more time to develop, so if the requirements are some derivative of that functionality I can give a pretty accurate estimate for how long it will take to build. However once team size and project scope expands, you have Developer A who is great at the assigned tasks and can finish a deliverable scoped at two weeks in two afternoons. Meanwhile, you have Developer B who is not so great at the assigned tasks, and requires a lot of hand-holding and assistance to build a below-par version of what the client expects. This mixture leads to ridiculously inaccurate estimates. What it usually boils down to on these projects is a spreadsheet written by an out-of-touch project manager who has to answer to a senior manager and pulls a timeframe out of thin air. A lot of planning and documenting goes into filling about 2/3 of this timeframe, and then the last 1/3 is spent killing yourself trying to finish a shitload of work in a short time frame to meet the original estimate so that the PM can show that he's really good at estimates! I've been through this process so many times and think about it constantly and have come to the conclusion that it's done this way because quite simply, there is no better way that accounts for the client's demand to have a firm estimate in place.

jakejake 12y ago
I agree. I find the thinking of developers here is all over the place due to the variety of types of work we're all doing. But some people take a hard-line approach to estimates based on the recommendation of others who are working in a totally different environment. If you are in the consulting business and you refuse to give estimates, then you simply will miss out on a huge amount of opportunities. That's just reality. No amount of explaining your methodology is going to get you a large corporate contact if you can't provide a quote. If you have no interest in that type of work, then that's fine, but there are plenty of people who do make their living that way. If you are on a product team, you may have an understanding business who realize the nature of programming. But you still have to work with the company so that press releases, support documentation, marketing, etc can get done. The sales and support teams may need training on features. So there is some degree of estimations that are still needed. As far as other types of ground-breaking experimental research programming - I can't really speak on that subject as far as deadlines because I've never done that.

jakejake 12y ago

This is an interesting article to me as I'm currently making a series of screenshot videos to document a project that we're doing at my company. It is estimated at about 3 months and I'm recording the progress and everything to see if we hit our goals. I thought it would be fun to post them as we go, but for competitive reasons I'm going to hold off until we actually get it done and then post them all. The videos so far are turning out to be somewhat long (10 minutes reviewing each week of the project) so I'm wondering if anybody will actually care about viewing such a thing?

alkonaut 12y ago

Estimates will always suck for 10 of them, but they work for large numbers (you can tweak the knobs to compensate for bad estimates). My experience after around 5000 stories and 100 man years (single project) is that we are slowly approaching acceptable accuracy!

andyhoff 12y ago

#NoEstimates to me is often an indicator of poor company culture. It immediately makes me think of shops where there's a disconnect between developers and the rest of the organization. The business and product people are unable to explain why they need estimates. Often they don't know it themselves and are just passing on the request from their bosses or customers. They hold devs accountable for estimates even if the requirements, priorities and teams change. They also think estimating is free - they don't realise that producing meaningful estimates takes time and requires a deep understanding of the code base. It also requires clear, precise requirements which they are unable to provide. Developers at these shops believe their single responsibility is producing elegant code. They don't have to prioritise features based on their cost and value; and they don't have to communicate with clients, investors or sponsors. Many devs never learned estimating, that's why they call it an "art". They spend forever to produce estimates that turn out to be way off, even if requirements and circumstances don't change. The lazy way out is to say: Estimating is a waste of time because estimates are almost always wrong. I have seen estimating done right: It took about 5%-10% of the overall effort spent. It helped make or break business cases, prioritise features and manage client expecations. It raised questions that, if left unanswered, could have resulted in massive cost explosions and unhappy customers later on. Key cultural ingredients: - Business and product people don't live on an island. They understand that estimating is neither free nor instant. They work close enough with developers to know what level of detail is necessary and they also understand the value of refactoring, test automation, pair programming, etc. - Developers don't live on an island. They are involved in product decisions and client communication, so they understand why people are asking for estimates. They not only take pride in the quality of their code but also in their ability to deliver features quickly - Estimates are not used to crucify developers, but the company culture allows an open and forward-looking conversation when the actual effort deviates a lot - Estimating is seen as a skill. Becoming good at it (ie. accurate and efficient) is a requirement to get senior dev roles - Everybody understands that when the world around them changes, the estimates change too Final note: work should be estimated in line with the predictability of the business. If your company is pivoting every 8 weeks then there's no use in estimating 6 months out. If you have a successful app for iOS and consider expanding to other platforms, it's probably worth estimating

12y ago

derriz 12y ago

Reasonable time cost estimation is certainly possible with software. It's not particularly easy but you certainly have a better chance if you at least expose yourself to the decades of hard research on the subject and not arrogantly imagine that everyone before you started programming of flogging your "agile approach" was an idiot and knew nothing about software development. Software estimating is not a particularly pleasant task - neither for developers (they generally have no training in the area and so don't even know how to approach the problem) nor managers (who have too little technical knowledge). And since 95% of development is writing in-house CRUD stuff or putting together lightly trafficked web-pages, it's tempting to bask in ignorance and pretend that not only is the task almost impossible anyway (and so pointless) but that in-fact it's unnecessary. And for IS department mickey-mouse projects, this is probably the case. Some of us however have had to pitch fixed price tenders for large software development projects, for example. And no, the customer isn't going to accept that it will be done when it's done and that we should just start a few sprints and see how it goes. And if you get the estimate wrong (too low), you screw yourself and lose money on the project - too high and you don't even get the contract. In this environment, you learn quickly that estimation is vital, difficult but possible with the appropriate effort. And yes I hated doing it the first time but it became almost satisfying after a few iterations having gained some confidence. This assumption that a "post-industrial", agile, folksy-anecdotal approach is appropriate for all software development really pisses me off. It breeds developer myopia, ignorance, self-importance and exceptionalism. Believe it or not, engineers have estimated, planned and executed very complex systems inside and outside of software. But it's only in software engineering do you find clowns earnestly claiming that estimating or planning developing some crappy CMS system is beyond human capabilities because software is so "different" and that estimating and planning a project like the Hoover dam was easy in comparison.

napoleond 12y ago
I agree that software estimating is absolutely possible and often necessary. However, it's important to keep in mind that software engineering has much less in common with the more traditional engineering disciplines than they have with each other. A big difference is the ability to heavily iterate on a design after it's been shipped (not in all cases, and within limits, but still generally much more than a structure or physical machine). So we often see procurement cycles which treat software development like a construction project or equipment manufacturing (because the organizations making the purchase--enterprise and government--have built their procurement processes around that sort of project) even though that cycle does not necessarily match the way software "should" be built. FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).

J_Boeg 12y ago

I wrote the essay and seems it sparked a good discussion in here :-) Can't comment on it all but the point I tried to get across was actually very closely related to the style of thinking most of you promote in here - focus on the outcome not the output, iterate fast and expect uncertainty in both cost and outcome. The principles I present is trying to do exactly that (IMO) while providing the structure to make informed decisions in terms of prioritization and risk. Basically - Make it short and simple for the team to estimate stuff so they can spend their time focusing on what's important (which is NOT worrying about whether 4 or 8 hours remain before you hit you original estimate and the stress, drop in motivation and even potential blame games that might follow from that) - and be disciplined enough about data to answer all the other questions people will ask anyway. Estimating in time sucks! And as I wrote, yes you can skip registering time on the individual user story if you find yourself in an environment where that is doable. You will loose a bit of data to make better informed decisions but I'll admit following the 80/20 rule that you probably should not do it if you can avoid it. Once the structure is set up it actually is quite lightweight (especially for the team but also the person collecting the data, both with and without the per user story time registration) and having at least some amount of real data does in my experience provide better and faster decisions in most contexts. But anyway, whether you agree or you don't thank you all for discussing and sharing. Never in a million years expected close to 13.000 users from 6 continents to visit my blog in less than 24 hours (and still rising) BR Jesper

dreamfactory2 12y ago

Or save yourself a lot of time by making each story worth 1 point and just count how many stories you have. They will average out over the course of a program (this is borne out by studies of many projects at Thoughtworks).