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.<p>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.<p>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!<p>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.
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.<p>My analogy would be someone asking how long it will take me to drive to my kids' school to pick them up.<p>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.<p>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.<p>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.
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.<p>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.<p>I wholeheartedly recommend it to anyone who can work that way.
I have said it before but I think it bears repeating.<p>Time estimations is an industrial way of thinking applied to a post-industrial world.<p>In the post industrial world time isn't the problem but rather project definition and scoping.<p>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)<p>In the post industrial world every project is about problem solving and scoping.<p>To put it into comparison.<p>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.
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.
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.<p>Now we are using historical data to predict how many calendar days the features scope may take with a specific confidence level.<p>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.<p>Here is article about our approach <a href="http://blog.lunarlogic.io/2015/project-management-estimation/" rel="nofollow">http://blog.lunarlogic.io/2015/project-management-estimation...</a>
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.<p>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).<p>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.<p>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.<p>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.
Simpler estimates are a step in the right direction, but this article is still advocating a very heavyweight (dare I say unagile?) process.<p>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.<p>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.
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.<p>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!<p>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.<p>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.<p>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)<p>BR
Jesper
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]).<p>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.<p>[0] obligatory self-promoting link -- <a href="http://confidest.com/articles/how-accurate-was-that-estimate/" rel="nofollow">http://confidest.com/articles/how-accurate-was-that-estimate...</a>
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.<p>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.
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.<p>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?
#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.<p>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.<p>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.<p>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.<p>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<p>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
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.
The whole game around estimates are a dirty way of dealing with other issues:<p>1) Can this be done before we run out of money and market opportunity?<p>2) How should other assets in the company be coordinated around the product. e.g. marketing needs a lead time to produce their campaign.<p>3) Scopeboxing.<p>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).<p>Estimates are intended to be converted into budget dollars (time * team-size * burn-rate) and are critically important signalling mechanisms. No money, no work.<p>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.<p>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 <i>"how much time do we have? we can get this much done in that time"</i> 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.<p>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).<p>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".<p>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.<p>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.<p>(#4) - To be able to say <i>"how much time do we have? we can get this much done in that time"</i> 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.<p>(#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.
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!
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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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 <i>needs</i> 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.
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).