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.
"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.
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?
"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.
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.
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.
This article read like it was written by a disconnected, manager-type. Not that I don't value the efforts of a skilled project manager, but that's a different matter entirely. Too often the process becomes more important than the outcome. I know the Agile evangelists will say that such managers are doing it wrong, but in that case I'm not sure I've ever seen it done right.
We are all (including many of the people who popularized the term) aware that it hasn't always worked out that way. But that's still the goal.
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.
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.
The difference with software is that if you have done it before you should have automated it. The great majority of programming is therefore design work. There is an answer here which is reversing the problem and simply timeboxing based on expected ROI and there is certainly no need for task estimation as a component of fixed price bidding, particularly where that has a lousy historical track record and wastes client money.
(I'm well aware that on many very large projects this is not the case and they are run like an old-fashioned production line with humans performing well-defined tasks - but this only illustrates the huge inefficiencies, lousy processes, and general ignorance of software development practises as standard in SI's.)
But aside from all that, how do you account for http://en.wikipedia.org/wiki/Planning_fallacy ?
I'd also be interested in how you apply cost estimation to debugging and other BAU tasks.
And the majority of development is (despite our egos) as mundane as this really. The effort is certainly NOT spent on design work; have you ever quantified the effort that goes into various aspects of delivering working production software?
Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates. You also calibrate your estimates with independent models and with empiricism (i.e. previous experiences).
But the literature is extensive on this topic - I can't give a summary here but if you are interested, there are worse places to start than with Boehm; deeply unfashionable I know but built on (shock! horror!) empiricism and not the rationalist (in a epistemological sense) sophistry which dominates the thinking of "agile visionaries".
Really it's like we've regressed to a pre-scientific age in the field of software engineering processes. Most of the debate seems about as relevant as arguing about how many angels can dance on the head of a pin. It seem actually observing and measuring reality went out of fashion sometime in the 90s.
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).
And the majority of (non-software) engineering projects also involve iteration.
The majority of software projects, I believe, can be estimated with reasonable accuracy as long as you ensure the project is a development project and not a research project. Most of the literature on this subject classify the types of software projects but nearly all recognize a category of "research project" and most agree you cannot estimate such a project. Note this finding applies to all branches of engineering.
A major problem I see with software engineering is developer ego resisting accepting that most of what they do is mundane and has been done many times before. They resist this ego-deflating fact by trying to turn every project into a "research" project; thus instead of using simple boring dependable tools (let's say Apache, MariaDb or Postgres and Php) to deliver working software, many developers/geeks (and I consider myself one) will try their utmost to turn the project into a research project. So it will be proposed to use a Hadoop cluster for storage and the latest cutting edge ORM tool with load-balancing and an XML based messaging bus talking to a front end written using Nimgorust or whatever cool new programming language is out there. Of course, estimating such a project is an order of magnitude more difficult than a project involving mature well-known tools. But this difficulty is a product of technical decisions (which you can control) and not inherent in the task of delivering working software.
In my vertical what happens is that customers field optimistic estimates from vendors much less qualified than you. But customers have no basis to know those estimates are fanciful. So they rely on a fanciful estimate from an unscrupulous vendor, and then get stuck.
Estimates are not judged on being right, they're judged on being low. In that environment, the only winning move is not to play.
Obviously in some verticals there could be people technically qualified to evaluate the incoming bids. I'm just reporting that it isn't the case where I work.
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.
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."
"Developer, will I be able to catch the next train if I walk, or do I need to get a taxi?"
"Estimating is a complete waste of time"
"But I just want to know if I need to spend money on a taxi. It's two miles away and I don't have any bags, and the train leaves in one hour"
"Start thinking post-industrially"
"FFS, I just want to know how long it'll take me to get to the station!"
So what's new here? That estimating an unknown task is silly? Well of course it is! But saying estimates are useless is also daft since there are plenty of times we know a fair amount about the problem, and knowing how long things are likely to take is very helpful in deciding what to do next.
If someone asks me how long it'll take to add a bit more information onto a page that we already have in the database, I can give them a fairly good answer since it's a problem that we've done plenty of times and therefore have a good idea about how long it's likely to take. If they want me to find new data sources and integrate them then I can tell them we've never spent less than X weeks doing that so we have to assume it'll take at least that long. If X weeks doesn't seem like a worthwhile investment of time, then even this level of estimation has been useful.
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.
What we manufacture in this industry is deltas to software products.
Clients often want a reasonable idea of how long it will take for a piece of work in the production line to make it to the factory door.
Velocity works well in that environment. It asks "how long will it take this piece to reach the door?", not "if I want a pile of deltas this high outside the factory door, how long will that take?"
The former can be derived from actual fresh data. The latter is an estimate built from adding up other estimates and is harder to rely on.
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.
This is an accurate description of my last job using Agile practices. This was a shrinkwrapped product too. No customer demanding estimates, in the midst of fundamental architecture changes, and people still trying to slice-n-dice blue-sky new product development into sprints and user stories. The estimates were a joke and quality suffered because people rushed to get stuff done for the 3 week sprint deadline. All because some manager wanted it. Fucking stupid.
Also estimation and agile do work, if done with some forethought - I wrote about that here: https://www.wittenburg.co.uk/Entry.aspx?id=db2d81dc-c435-42c....
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.
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.
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.
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
As long as you don't let the difficulty numbers get translated back into dates, you get the best of both worlds. You don't waste time on projects that aren't worth doing, and there's no deadlines and estimates to cause friction.
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.
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...
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
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...
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.
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?
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.
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.
