How to respond when you are asked for an estimate?
softwareengineering.stackexchange.com
softwareengineering.stackexchange.com
Most people really suck at expectation management, much more than they suck at estimating work.
I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else.
So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.
> Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.
> [La Forge goes back to work; Scotty follows slowly]
> Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.
> Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
> Scotty: How long will it really take?
> Lt. Commander Geordi La Forge: An hour!
> Scotty: Oh, you didn't tell him how long it would really take, did ya?
> Lt. Commander Geordi La Forge: Well, of course I did.
> Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
Sometimes there are legitimate reasons to come up with schedules that are as accurate as you can make them, understanding that stuff almost always happens. Sometimes a project or some dependencies don't make sense if they can't be done by a particular date.
But, yeah, it's good advice in general. For most of the work I do (not programming), I have a pretty good sense of the minimum time I need and I almost always significantly pad that to accommodate priority interrupts or just so I can take a bit of extra time if I feel the task warrants it.
LaForge was a competent engineering manager. The writers tended to focus more on the character's people management skills (and, sometimes, terrible personal relationship stuff). He kept things running smoothly. He was smart. You could imagine a detailed maintenance work log for every system on the ship, and there'd be no gaps in it ever since he took the position of chief engineer.
But while Scotty cared about his staff, it was the machinery that he knew inside and out. He never needed to conjure up a hologram of the designer of the warp engines, because he knew them as well as anyone else. His maintenance logs would have gaps because he'd know which things actually needed regular attention, and which ones were just bureaucratic nonsense. He didn't just understand all of it on the technician level, but on the theoretical level too, enabling him to pull off some unlikely saves.
He actually was a miracle worker and maybe one of the best fictional representations of an engineer, and that one scene was written to make him look a little more like a bureaucrat.
LaForge is competent, he's also newer in his overall career. Scotty has been around the block so many times he knows where every crack and seam is.
That was a moment where Scotty's wisdom was being handed down; it's OK to know what it will take, but stuff happens, and there's also the potential to hand tasks off to less senior staff that might not do it at perfect speed. Giving a padded estimate gives you options and room for corrections if there are issues.
(https://en.wikiquote.org/wiki/Star_Trek_III:_The_Search_for_...) see the first bit of dialogue in this page.
Also I don't think it makes him seem like a bureaucrat. I'm no manager. I'm an engineer at the bottom of the org chart, but I still need to deliver estimates to my supervisor. And even if I'm an exceptional engineer, I can choose to estimate the time required for a task as though I were merely average.
Ran it up the flagpole. It got cut in half. Fortunately I didn't need to change the schedule I had drawn up. I just said each box is now half a day. (This was before we used computers for this sort of thing.) As I recall, the job came in very close to my initial estimate.
Instead, try actually estimating the work. List components touched. List technologies involved. List screens needed. All of these are measurable. A point estimate is too easy to get wrong and impossible to question.
Elaborate work estimations are a fools errand. No one can argue that you can make far more accurate estimates by spending 50% of your time doing research for estimates instead of 2% of your time. But spending 2% of your time on estimates also means you'll finish every project twice as fast.
Now many people doing this use a "point system" where they escalate the allowed votes as you go up. This is a neat heuristic that accounts for some uncertainty. But it really only boils down the estimates to the easy to estimate tasks. Which are often not worth estimating.
I'm not claiming to be elaborate. But do realize if someone estimates a house project is large, I will have less faith in their estimate compared to someone estimating it will take about 300 square feet of tile, plus for gallons of paint and probably to gallons of mortar.
One shows they have thought and didn't gut shot it. Even better, we have something to actually burn down in the supplies. We can also gauge it with previous jobs to know how long it took to use that much supplies.
Software is tougher, because we don't have the same supplies. But this is why you don't list lines of code, but required screens, technical integrations, and general features. Agreed that you don't want to get too elaborate. But also don't give me some stupid t-shirt sizing or other nonsense.
Not the least of the reasons why, is negotiating a size is dumb. There are literally no reasons not to convince someone they estimated high. However, cutting an integration is a choice that has obvious downsides to account for any speed up in delivery. Even better, it is empowering to choose what you won't deliver, instead of having it chosen for you.
When I was referring to "points", I was talking about Agile development. It's planning process is far more accurate than time estimates because it uses points as a measure of the relative work in tasks. It's far easier to accurately say this task is a 3, and this other task is a 5, than to estimate their hours. In Agile planners don't need time estimates because they prioritize tasks based on relative work required (and customer benefit), and the team just works down the priorities until end of it's sprint, and then ships whatever got done.
In particular, those point estimates are not negotiable. Which is why they are less meaningful. Talking someone down from a 5 to a 3 just convinced them to agree they can do a task faster. Presumably at higher risk. Convincing them they don't have to do two of the tasks? That is a clear win, because it is work they don't have to do. Not work they have to try and do faster.
There is also the generative problem of software. As time on a project goes on, changes become slower. So, some task may be a 5 if done now, but a 12 if done later. Similarly, some tasks can piggy back of effort on others, such that they get cheaper in terms of work needed. Though, with time, they probably keep the high time cost.
All tasks should be pointed in Agile. If anything was left out it's on the team to make sure a story is written for it. For example lets say my PM wants us to estimate 10 stories for the next sprint. If I know I have to do some low level work to update the database to make those 10 stories feasible I'll say we need a story for that, and it needs to be our highest priority since all the other stories are dependent upon it.
But good Agile is done with a Kanban approach, we have a ranked board of tasks, and work on the highest priorities first. If we forgot a task, we add it to the board and point it, and our PMM/PM prioritize it. This can be done at any time in the schedule. When we reach the end of the sprint, we make sure all the completed tasks are done, bug free and we ship.
Then we start a new sprint, working on the remaining tasks, pointing new ones, and working from the top of the Kanban board again.
No one ever need to make a single time estimate, or waste more than a tiny fraction of development time doing any type of estimation.
My main concern here is precisely that it is not negotiated. I like the idea of making sure folks are on the same page. However, the idea of another meeting to discuss what we should instead be building is nauseating.
Instead, meetings that decide what we are not going to build are much more productive feeling. Which is why they should be negotiations. If there is just a list of tasks that has to be done, just keep the list up to date and let the team work on them. If there is concern on priority, make a choice and let the team weigh in. Don't add to their work by asking them to prioritize on behalf of stakeholders.
And kanban is good, but really needs handoff spots between teams. Otherwise, you are just in a constant swarm. Often rewarding the fastest workers. Which is fine, but risks alienating the slower ones that could contribute in other circumstances.
My viewpoint is let marketing estimate the value of features, my job is to give them a rough estimate of how hard each one is to build, and they can decide priorities based on those two things, and tell me what to work on first. If I go too fast and lesser developers feel left out, I'm happy to pair program and do code reviews with them to help them improve.
Yea, all my projects have to have a defined release process (code freeze, final bug fixing/deferall, final acceptance tests), you can't kanban your way through that, but you can kanban your way to it.
And I should be very clear, if what you are doing is working for you, that is by far the most important thing. I am decidedly not trying to convince you to stop and change.
Further, If it can be formulated and shared with others, I'd be interested in the results. However, I have come to find that I do not expect things to generalize between people nearly as often as my instincts would want them to.
I do take this as a challenge to how I've viewed stuff. Currently, I'm on leave for about a month, but when I get back I plan on paying more attention to the process. I'm hoping I don't miss any retrospectives on projects that were finishing up as I took leave. I'm not convinced people typically zero in on the important points. I am still fully convinced you should always try.
Execs view it as being able to make informed decisions about where to spend the company's time and money.
Let's say you have projects A and B you want to do, and you've estimated revenues from each at $11 MM and $4 MM. You really want to do A, since it would establish a business relationship with a new strategic partner, but estimates come back that A will take 16 weeks and B will take 4 weeks. You only have time to focus on one project at a time, so you choose B to try to capture a quick turnaround before moving onto A. Plus it would make an existing partner happy.
Execs know from experience that the engineering estimates usually suck. Sometimes they're really high and sometimes they're really low. Execs decide as long as B doesn't exceed 5 weeks, we're OK. They don't communicate this down the chain because if everyone knows 5 weeks is the "real" number they'll (grudgingly) accept, they are pretty sure someone somewhere in the chain will spend a week optimizing the test harness or refactoring the build process or something.
At week 3, engineering says they're gonna need 2 more weeks. Execs: Sure.
At week 4, engineering says they're gonna need 2 more weeks again. Execs are annoyed but now the work is mostly done, and everyone promises on their children's lives it will actually be done in 6 weeks, so they let it finish.
At week 5, we're still on track for week 6. Execs: Sure.
At week 6, we're gonna need another week. Execs: Whatever. At this point they've abandoned all faith in this engineering team. They re-task some other critical part of the business with beginning work on project A. Some part of the business suffers.
B actually takes 7 weeks when all is said and done. Execs wouldn't have bothered with it if they knew that up front. Everyone involved in B takes a reputation hit: the product manager, the project manager, the engineering manager, and the engineers themselves. The people who blame others get an even bigger reputation hit.
Now there's pressure from some sides of the exec table to make up time on project A and get the estimate below 16 weeks from a team that had nothing to do with B.
Happily for everyone but the first team, it turns out the other team is able to get project A out the door in just 12 weeks. Everyone on the first team takes another reputation hit.
You might say that the root problem was the estimate for B was too low. That is a problem, but the fact that the estimate for A was 25% is equally problematic. Had either estimate been more accurate, the company would have focuses on A first.
All of these execs are accountable to the CEO, who's accountable to the board. The CPO or CTO or whoever are not escaping unscathed from this, because at the next board meeting the CEO has to answer for why project A was delayed into Q2.
From the exec's standpoint, it looks like we can't be trusted. But the truth is the process can't be trusted. Never give out time estimates. Use Agile and point planning, and relative cost estimates.
In your example, the team should have said that we estimate A is 4x as much work as B. Pick one, we'll get it done as fast as possible.
You can have a fixed time schedule, or a fixed project feature set. You can't have both, without the project being late, and features being compromised.
You identified the first one correctly: they had the lead engineers estimate in isolation and not involve the team in any way until the end. Beyond being a bad way to estimate, it's a bad way to manage a team.
But then you said you should never provide a real estimate. That conclusion doesn't really follow. The leadership team has to come up with real estimates. "A is 4x as much work as B" is good information, but it's pretty useless when it comes to actual calendar planning.
The second issue, and the larger one, is that long, stop-the-world refactors (or rewrites) are the fastest way for the engineering team to lose all credibility in my experience. The business keeps moving even if new feature development doesn't. I've found incremental refactors to be the best way to go. And those are much easier to estimate.
As far as schedule vs. feature set, if you estimate properly and prioritize all of the least-needed features at the end, if you find yourself falling behind you just pop those tasks off. But you build that contingency in and communicate it up front.
In our case bogging down the entire team in time estimates would have wasted even more time and we would have accomplished even less. Had we kept to an agile process with sprints we could have met the fixed schedule expected, and delivered more benefits given that losing our leads in planning for weeks on end meant they contributed relatively little to the refactor.
What I said was no contradiction. How does one arrive at the finish date? Finger in the air? There are essential features and nice-to-haves, and to get a delivery date you need to estimate them. But it's an estimate and so you plan for contingencies.
At the end they required twice a day reporting meetings, the standup to say what you were doing, and an end of day status meeting to say what you did so it could be communicated to the exacs. Two more meetings where zero development gets done.
I am not really disagreeing with you. It's reasonable to do basic estimation in most projects. Usually marketing/management need to know when something can ship in order to plan the launch plan. So you figure out how long you need to be really confident the essentials will be finished, and use the nice-to-haves as padding that can be deferred if necessary to make the date.
But if you don't have to hit a specific date, say the product is already shipping and just needs regular constant improvement, just do it in fixed schedule sprints. Focus on the highest priorities every sprint, get as many done as possible during it, ship the new release, rinse and repeat. A well run sprint can be great because eschewing time estimates means more time spent actually building the product.
But if you are forced to give them, never give a single number. Use ranges. Your range for a confident estimate should be roughly 4x between the fastest and longest components. For example, 1 to 4 hours for a task you are very confident about. For things you have less confidence on, your range should be closer to 8X.
Why do this? Because wide ranges are the ONLY accurate software engineering time estimates. You need to communicate the inherent lack of precision in any estimate. For every time estimate you don't know
1) How many hours a day you'll be allowed to actually code, outside of meetings, standup, planning sessions, emergency bug fixes, etc, etc. 2) Which member of your team will actually end up doing it, the fastest one, the slowest one, or someone in between. 3) How many days will be lost to illness or personal issues. 4) How much the actual feature or story will change as it's developed and they realize the design is actual shit. 5) How much other code will need to be changed when you actually rip the lid off some of the older code it will interact with.
etc. etc.
Scrum has a similar technique only allowing Fibonacci numbers, I think the reasoning behind it is similar.
Obviously the receiver of the estimate should know that you are using this method, otherwise they might start questioning you thinking this estimate should only be 17 for example.
On the other hand: Do it. Laugh. Laugh in his face when you are called to help on a project that isn't ready after 1 year and started without you. When they show some wire-frames and ask you how long it takes without telling you about the actual technology used for the project.
Summer 2015 I was uninvited from a project meeting. My coworker was planning the project and discussed it a bit with me. He wasn't the one who decided that I shouldn't take part.
Summer/Fall 2016 and the project isn't going anywhere. I'm invited to help. I do my best, besides the other projects.
January 2017 and my coworker is gone. He gave his 3 months (+ x days) notice and told me December 2016. Shortly after it I gave my 4 1/2 months notice.
The new deadline for the project was May 2017.
They launched November 2017.
"Cool story, bro. What was it? Some revolutionary VR or AR application? AI supported super gadget? Brainwave reader and interpreter?"
…
It was the company's own website.
Any project like this one can often go off the rails if the right decision makers are not involved. This is not necessarily the fault of the project leader as it can be unintuitive in bureaucracies.
May of 2015: hired at startup that wants to use Natural Language Processing so salespeople can send text messages directly to their CRM (Salesforce, PipeDrive, etc). Very excited about the project. The app's initial UI design is a traditional one, with NLP helping to smooth the basic task. The full app would take about a year to build but we all agreed we could have an MVP by August.
August of 2015: without consulting anyone on the tech team, the Board Of Directors decides the app should get rid of all standard UI elements: no forms, no buttons, no links, no drop down menus. Instead, the interface should be a pure chat app. This makes the project much more ambitious, which I was very excited about, but which I felt would delay the project 2 or 3 months. Nobody was happy with my estimate.
September of 2015: the CEO was able to show a demo to the Board Of Directors. The demo was an illusion, as we had no error handling, and it only worked for some carefully planned examples, but I thought it was a good sign that we could show the Board that we were making progress. Unknown to me, the Board then asked the CEO for real feedback from real customers at the next meeting, a month later, in October. There was no possible way for us to finish the product, and find customers, and get feedback, all in a month, but the CEO was a bit of a coward, so he promised the Board we would do this.
October of 2015: obviously we did not have customer feedback by the next meeting of the Board. At this point the Board decides we have missed our schedule and they begin to panic. We are slowed by the fact that our "NLP expert" is inexperienced. Myself and our iPhone programmer tell management that we need to fire the current NLP guy and hire someone with real experience. Management initially agrees but then later changes its mind, for reasons unstated.
November of 2015: we get a basic demo working, and it has enough error checking that we can show it to potential customers, and not be entirely embarrassed. But the stress of the previous month has wrecked relationships inside the company, people are shouting at each other constantly. At this point I step away from the project, but I remain on friendly terms with the guy who is doing the iPhone programming.
January of 2016: company gets two trial customers, but these customers won't pay for the product. The NLP engine is improving, but at glacial speed, as the "NLP expert" is at the beginning of his career. He was a nice person, and I can believe he will eventually become a good programmer, but it didn't make sense that a company that wanted to move fast also remained so loyal to a guy who could not do what was needed. An established company could/should afford to have an apprenticeship program, but a fast moving startup can not offer an apprenticeship to someone working on a core technology.
April of 2016: the iPhone guy again asks management to find a new NLP expert, someone who can move the company forward. Management reacts by listing every bug ever discovered in the iPhone app, as a way of telling the iPhone guy to shut up.
May of 2016: the iPhone programmer quits and gets a job elsewhere.
June of 2016: the company is almost out of money, so it cuts back on spending, reduces the team.
summer and autumn of 2016: without much staff, the company crawls along at a glacial pace
Early 2017: the company gets more funding, begins moving forward again.
Summer of 2017: the company now has a few trial customers, but they are paying trial rates, which is to say, almost nothing. The company is not anywhere close to the breakeven point.
The company continues to burn money without making much progress. There are clearly some fundamental leadership issues that should be addressed, and one of those are the ways that estimates and budgets are created. Also, the company would be in much better shape if the leadership listened to feedback from the tech team.
I wrote about all of this in detail here:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
Maybe the most important thing to remember is to beware of keeping your old behavior with regard to estimating things when there's a sudden change in the management structure. You may go from someone who understands development and knows how to interpret and present a good-faith estimate from developers to higher ups, to someone who just presents your estimates up the chain verbatim. And that shift may not be obvious to the developer until the fallout from a bad estimate gets blamed on you.
Personality of the estimator plays a huge part and the voltile/stable essay was a great shortcut for understanding this. A voltile will hit the estimate or beat it. It'll be cowboy all day long and god help the company if it needs to be maintained. I've had a few dev leads like this. They'll take the tricky bits and do it alone. At night. On the weekend. Half asleep. Then, there is the stable. They'll never hit their original estimate. The most egregious won't get beyond the proof of concept without some serious prodding. When the project is done, it's meticulous, but we rarely get to that point because of the daily 6 hour long discussions about naming...
If it's Project Manager, that's crazy.
A project manager's key role is to save money on developers. It's a hugely cost efficient role when done well.
A product manager's job is to ensure the product meets customer needs/requirements. Having them do menial tasks to remove roadblocks for developers is totally orthogonal to their most important tasks.
1 hour becomes 2 days. 4 days becomes 5 weeks. And so forth.
I'm actually somewhat decent at estimating well defined work, so it actually annoys him when one day is one day; but I appreciate his work when some odd stumbling block (usually political; my estimating skills crash and burn when it involves working with humans) comes up and the time doubles or triples the estimate.
A year is an eternity anyway, you shouldn’t start a project with nothing coming out of it before a year, that’s suicide on so many plans.
So, 1 year is the time the first interns team will work on it, 10 year is the duration before the project is retired. Looks like both estimates were right.
My engineering manager at a games company I worked for told me that "three weeks" was the estimate that really meant they had no idea how long it would take, because the task was too hard to estimate. Anything longer than three weeks could, and did in fact, sometimes take six months.
Large projects can always be broken down into smaller, more well-understood tasks. You can't build something large all at once. Large estimates are just an indication of a lack of discipline in planning because they mean that the project hasn't been decomposed into its constituent tasks. Large estimates are lazy and can only be right out of sheer luck. In the team's I manage, I don't let anyone start a story with an estimate of more than two days.
Are you being serious? That only works if the people consuming these estimates don't have a clue and therefore can't call BS. This would get me aughed out of my job.
If I were to estimate things as suggested in this thread, it seems to me things would never get done. Ever. It simply boggles my mind people want and will fudge estimates on this scale.
It's only three days in to the project that you realize there's a mismatch between what you need and what the project provides. You start a conversation with the project's lead developer; but they're only able to have half of any given conversation in a day. How hard would it be to spend five days researching the cause and severity of the mismatch while discussing solutions with the remote developer?
There's 8 days.
You decide to write a patch for the open source project shepherd it through the internal and external approval process, burning up another two weeks of time.
18 days.
You finally get back and finish the original project, redoing a fair bit of work to account for the changes your patch introduced.
23 days.
You're interrupted throughout this process several times by fires in production that need to be fixed RIGHT NOW.
28 days.
Let's make the assumption your PM did their little trick, and slated 2 months for this project. Despite your own estimate being off (through no ill-will by anybody) by about 6x, your work is still completed before it's expected, and the teams depending upon your work are happy as clams. Even if it had finished in the original 5 days, everyone would be thrilled, and you'd get more work to do.
From the PM's point of view, it's a win-win situation. From your point of view, the worst you have to endure is a twinge of "don't you trust me?", offset by the relief of not having to answer "why isn't it done yet" every day from day 6 on.
While your example showed how project implementation can creep up, I already knew that and my problem is more my inability to give accurate estimates and people's willingness to stretch their estimates by a lot. I KNOW some of you will not agree with me, but I think that giving 4x as long estimates will lead to developers spending more time on the actual implementation without noticeable improvements in the delivery. I know my natural tendency is to do so.
You could deliver something in 1 hour, BUT, the customer/person that could answer you WHAT to do exactly will take days/weeks to be AVAILABLE.
This is not a joke.
For one of my very recent jobs, I need to wait 1 FULL YEAR TO MOVE ON. Then weeks after that. Despite already being paid in half!
--
Developer time is NOT ONLY the time the developer smash the keyboard.
What decision are you trying to make using this estimate? Understanding context helps you to understand what sort of estimate is needed - or whether an estimate is needed at all.
The best thing for both the company and yourself is to try to be as high bandwidth as possible and discuss all the potential risks and tradeoffs. Find out what the real goals are so you can optimize a solution to provide for them. Many managers and customers get stuck early on with a particular approach, but if you apply some creative engineering you can come up with a solution which is easier, or folds in with some other goal you were already working on, leverages existing functionality etc.
its on you to express it in terms they can understand from their own position: risk, cost, headcount, schedule, dropping existing features.
if your organization doesn't want to engage in that kind of semantically meaningful discussion, or comes back and says 'I know you said 3 months, but get in don't in 2 weeks' then you need to start managing upward and looking for a new job. or you can just overestimate, and enjoy your free 2 hour lunches for as long as the money lasts.
When people say they need feature A, B and C and ask when I will have it done, I split it up in tasks that take below a day, estimate these tasks and add 50% for safety.
This works in most cases.
But often the reason why projects won't finish on time is, because people don't know what they want.
They ask for A, B, C, you estimate it right or probably too pessimistic and get done ahead of time, but still the project is late in the end because they forgot about D, E, F, G, H and J. In the end you can fit D, E and maybe F in the time you have left because you got A, B, C done quicker than estimated but G, H and J are still missing.
If they come back and say, "oh, we forgot to say we also need D", then the response should be, "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal?" Or, if you're under budget and you're charging hourly rates instead of a fixed cost, you might even say you can probably add it without going over budget.
PS: I just realized that you're probably talking about internal "clients" so there's no contract or even payment. But I think the same general idea applies. When they bring up extra features, you just say that it's going to take additional time.
edit 2: I guess this doesn't actually help with getting the project done on time. The initial time estimate is still going to be off for the reasons you mentioned. So this comment isn't really an argument against anything you wrote.
PM: I want a bridge. When can we start using it?
Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry?
PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.
If you are lucky, you will recognize from their "requirements" (often just a verbal description) that they are describing the characteristics of a bridge (e.g. continuous bidirectional flow), not a ferry.
More typically, after you have built the car ferry, they ask why it doesn't implement continuous bidirectional flow despite never specifying that as a requirement.
Usually they both suck. The manager will send an unclear email. The developer will start developing right away. None have any idea what they are supposed to do, why or when.
For managers the value of a developer is the solutions they build divided by the amount of time and information they need to build it.
You have always the choice between delaying further or delivering something they like as soon as possible, risking they don't like it.
Normally you would need a prototype, throw it away after you saw the reactions to it and build something new.
But often there is no money for this :/
A client wants something. In software, the something is usually complex and not well understood, a contract is done to do a something like that. During the project, they will invariably find new information and issues, the scope will change, sometimes dramatically.
For the comparison, consider a building. You want to construct a new building, it's easy, you say what land you have, the engineers will tell you how large and tall they can build on that, you get to pick the interiors among a few office/industrial layouts. You can all understand what is being discussed.
In software project, there is no physical limitations and no regulations. The limits are not clearly defined, noone will see or believe them. Worse, you have to integrate with clients/new/legacy systems that are not well defined and unknown ahead of time, nothing you can plan about that.
What happens in practice is they didn't realize they were asking for additional features -- they thought they were asking for D, E, F (etc) all along in the initial request. They just assumed "Email signup link" also meant spam handling, re-sending, prevention of double sending, etc. Good product managers account for these obvious things, and leave padding for the unexpected. But good product managers are rare. Most software developers I know have never even met one. So instead you have a political dance where you try to plan for the things they aren't telling you, along with all the _expected unexpected's_ that come up in normal software development, and set your deadline's appropriately. Definitely the worst part of software development.
1. It's never repeatable. Nearly every single thing built in software is being built for the first time. Even if it's some government CRUD application, and even if you're leveraging sixteen popular software frameworks to build it, that application will still be in some way different from other applications in the same niche. There's no blueprint for building software; mechanics have a gigantic (sometimes accurate) database of the time required to do a variety of jobs, tract home builders are all building the same thing over and over ... the closest that software ever gets to that is themes or skins for frontend UI, and even those inevitably end up getting customized in some way.
2. Nobody wants to pay to build a blueprint. The only way in the software industry to figure out how complex a particular application is going to be is to build it. Developing an accurate spec is exactly as expensive as building the actual application. This is because the "engineering" part of software engineering is still practically nonexistent.
3. And while we're on the topic of engineering: there are no standards. Or, there are thousands of different standards, depending on how you look at it. That CRUD application could be built with one of many different interfaces -- should it emulate data entry terminals, with simple tab-navigable text fields? Should it use Google's "Material" UI? Bootstrap? There's no comprehensive study which has compared the amount of end user effort required to use each interface, and therefore there's no industry standard which says, "this is always the right way to build this thing given these constraints". Compare to something like a low voltage contractor's license, which expects you to be familiar with the different types of cable to use in different building environments.
4. It's buggy as hell. Ok, so you're experienced enough to navigate your way through everything else up above and not get burned too badly. You have a preferred toolkit, you specialize in a particular niche, cool. Well, today, Chrome just released an update that broke the way your application handles cached content. (Happened to me.) The vendor for one of your frameworks released an urgent security update that completely broke critical functionality in an unrelated part of the application. (Happened to me.) The two libraries you're using together, which don't use any of the same globals and should be entirely isolated from eachother, are still somehow interfering in a way that's not covered by the sparse documentation. (Happened to me.) There are millions upon millions of lines of code involved in every single interaction with a computer now, and they are imperfect. Many of them are written by amateurs, people who -- even though they're getting paid to write code -- have only been in the industry for a couple of years and they're still re-learning all of the same lessons that everyone else before them had to learn through trial and error.
5. Too many programmers like shiny new things. We could fix a lot of the above if we slowed down and "refactored" our industry -- started doing real usability studies, establishing standards for storing sensitive information, more rigorously separating security and feature updates. But, nobody really wants to do that. They want the new thing: the new programming language, the new framework, the new browser feature, the new toolchain. I think this is largely because while programmers spend a lot of their time talking to machines, they aren't machines themselves. They need a steady stream of new stuff to stave off the boredom. It's also a good way to improve your resume or income. If a new Widget comes out, and you immediately learn Widget, you're now one of very few people in the world that knows Widget. Now, if you convince your bosses or customers to use Widget, you're the only person that they can go to for help with Widget.
So there's a lot of immaturity, and it's kind of a mess, but it's also a pace of technological development that's unprecedented in the history of humankind.
Yeah, it's an interesting point, because it's not even "many", it's "most". There's a talk by Bob Martin where he goes into this. His statistic was that the number of working programmers is doubling every five years, which means that at any given time, around half the population has less than five years' experience.
The best (and fastest) way to build something is with minimal specs, and modifying as you go along. As your clients (internal or otherwise) actually get to use features as they are built, they'll provide tons of input that they wouldn't ever have put in a spec.
This is also why you should never, ever, do fixed bid work in software development.
The best way is to overshoot the time and offer the flat rate. If they bite, I can treble my usual rate, if they come back with a hard negation, I take that as an indicator that they will be difficult to work with.
It's a a tough balance.
By the way, watch out when changing from daily rate to project. Legally, you have to deliver the project when you bill for a project, so you are forced to make a contract with well defined project scope to cover your ass. It's quite a lot of (billable) hassle.
Interesting you bring that up though. I had a client through a contracting company. After the project was done, they said they actually asked for something more, which was never even discussed. I ended up partly unpaid even though I was clearly correct.
The law works when the money is worth chasing.
The law is never in your favor as a single man or small shop. It's too expensive to go to court, then determining what should have been done or not done as per the contract is a lengthy and uncertain proceeding.
Clients who wanna pay per project basically want to move the risk over to you. They should pay a premium. Write a solid contract and increase the fees/duration. Most should give up when you start increasing the quote just to establish the contract, it's easier to start a POC and see what could be achieved.
Don't estimate in a meeting. Let people go back to their desks to research and document the issue. Give them time. It takes longer, but it yields more accurate estimates.
Have the team meet up again afterward and let everyone discuss the estimates and how they arrived at each piece. Let the team come to a group consensus about each estimate.
By breaking it out into a series of small tasks, you also have a daily schedule and a daily benchmark to work against:
[x] X (2 hours est., 2 hours actual)
[x] Y (3 hours, 5 hours actual)
[ ] Z (1 hour)
Now you have a daily update: "I went 2 hours over on Y yesterday and didn't get to Z, but I stayed a little later to get Y finished. I'm at least 1 hour behind schedule, but I think I can make it up today and tomorrow."
This makes you super dependable to management and keeps you on task. Super dependable means you make them look good--which means you're first to get the choice assignments, first to get a bonus or raise, first to get a promotion.
Managers know that schedules occasionally slip; what they want is to know as early as humanly possible so they can make a decision about the project.
The rest of the world benefits far more from faster and more effective product development than it does schedule estimations.
Most of the time, you will give an estimate, and the manager will turn the sum of your estimates into a deadline. Don't fall into this trap.
for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is.
for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z).
or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day.
what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.
i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.)
i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.
The only accurate time estimate is a range with at minimum a 4x difference between best and worst case, and preferably more the less certain the estimate is.
1. Why do you need the estimate? Is it to get budget approval, or because you're trying to meet an approved budget? If they don't have budget approval then I'm going to charge them something to gather requirements and deliver an estimate. No budget approval = low on priority list.
2. We charge a blended rate of $xxx per hour. If you have a detailed requirements list I can tell you if we can do this within your budget. If they don't have a detailed requirements list then I'm going to charge them to provide one. After I have the requirements list completed I'm asking for their budget.
3. Don't want to pay for a requirements list? I understand. Its okay. Something like this typically costs (low bid), but that will likely change if the requirements are different then my assumptions.
Going to hold onto these. Good phrasing/ideas.
get a sense whether task is S, M, L, or XL from developers etc... and then multiply it by whatever factor you think S-XL should be in hours/days.
people can't seem to provide time-base estimates - but generally have a good sense of a complexity of a problem.
"Is this a hundreds of dollars or thousands of dollars problem" can work wonders.
1) Two months spent writing complete product requirements documentation, while engineers research and estimate all tasks and sub-tasks.
2) We start right now with the minimal documentation we have, using priorities Marketing has given us and work with Marketing to flesh out the details for every component as we build it.
In case 1), you get a schedule in two months. The schedule won't be accurate because it won't be able to anticipate everything. Most likely it won't be able to anticipate how product requirements will change during our lengthy development, and they most certainly will change given that Marketing isn't going to stop talking to customers or thinking of new ideas. But you'll have a schedule.
In case 2) I'll guarantee the project will be finished faster and be a better product. You don't get an accurate schedule either, but you also don't lie to yourself that the one you have is accurate.
1. optionally divide your project in arbitrary smaller tasks
2. for each subtask pick a range (min and max estimate) so that you‘re sure the actual time lies in the range 90% of the time.
3. imagine the following decision: you can draw one out of 9 black and 1 red marble. If you pick the red you get 10.000$. That‘s a chance of 90%.
OR: you can choose your estimate and get 10.000$ if it‘s correct.
If you think about this decision and rather pick the marble-game, then your estimate is too narrow and most likely not correct.
If you pick your estimate over the marble game, it‘s too wide, because you‘re more than 90% sure about it.
Adjust your estimate until the decision doesn‘t matter anymore and both the game and your estimate seem like equal chances to you.
4. my own addendum for people who are afraid of asking too much: double the result to take the stress of yourself.
Will you see a doctor who can't estimate how long a surgery will take?
Will you take a cab or a flight that refuses to give you an estimate?
Will you take a job that can't give you an estimate of what the salary range will be. They will figure it out when they pay you.
Come on, cut the rubbish folks. This is why we get no respect from non tech folks. Everything doesn't revolve around tech. Businesses have decisions to make based on time product gets to market. They have decisions to make based on cost of product. Estimates allows them to make such decisions.
Learning to give estimate is one of the best skills you could ever have as a developer.
Alternatively what I'll do is point out that their request is simply incomplete and I can help them create a better request, which I will then estimate (it's all still billable though).
Also worthwhile is to consider the overall likelihood of success for projects you take on (and what it implies for future work, quality of life while working with the client, etc). I wasted a lot of time early in my career on projects that I knew were doomed just because someone agreed to pay my rate.
I was approached by someone who wanted to hire me as a freelancer, but the requirements were quite vague. He wanted a general idea of how much I billed daily, but I really didn't know how to answer it. $300? $600? What's high enough to hook them, but not too high to push them away? How do you factor in risk? What if they don't like what I deliver?
This seems related to time estimation, but different enough to ask.
Another thing that sometimes works is giving a really high number, but then offering a "deal".
YMMV.
Last time I tried this, my rate was high enough that they balked. I'd like to avoid that, but still charge enough to make it worthwhile.
I thought it'd go like this: Start at double my highest rate, then wait for them to counteroffer. Commence negotiation. But last time they just walked.
Regular on site visits and full-time, local work? $1000/day minimum in the high cost of living area I'm in (Boston area). If they straight out walk at that, you dodged a bullet.
Bidding too high and losing the work is way, way better than bidding too low and getting it!
I don't know in what market you are, but 600e (=usd 715) is on the low end for skilled dev work in western europe excluding non-london uk, in my experience (so not slicing psd's or doing piecewise javascript website elements, I'm talking full custom systems). Don't compete on price unless you're desperate for the money. Life's too short to be nickle and dimed.
Big projects can suffer from this because little architecture is involved (and we worked on already existing systems). Otoh, I’ve seen no big local project that wasn’t an architectural mess once it hit a deadline hard. It is better to not have one than to have a set of rules that you must obey, while other parts of system don’t even care of or contradict these.
Personally I don’t believe this “I’ll get back to you with an estimate” thing. It is just first iteration where you go relax and try to formulate at least 5-10 questions that you think you should ask foremost to start building an estimate. If you come back with an answer instead, then it is still wrong, maybe even worse than random, since you estimated a different thing. For us, estimates and requirements always moved, as they were functions of delays and business priorities that change unpredictably. I didn’t like to deliver the entirety on a deadline because my job was to support that for years, not throw a bill at them and run, as all integrators did.
Maybe, maybe these SE-users are speaking about coding phase, when all “business analysis” was done perfectly. But ime it is you coder who collects all the knowledge, because no one can. Or it is you who is non-coding analyst who must estimate, because non-analytic coders don’t have a clue what a big picture is.
I like it, because it's true, it works, and it deals with the inherent uncertainty of software development by letting those who ask decide how much they want to pay for how much certainty.
The process of building software includes discussing what has the best impact to effort ratio. Both are estimates and will not come out as expected.
The logical response to managers that expect you to always hit deadlines is to inflate estimates enough that you will.
[It is ideal to understand the problem with "use cases" and "stories" is that they are a poor building block for estimation and development because they inevitably require further and further decomposition.]
1b. Formally (in writing) present the estimate, together with the known requirements upon which it is based.
1c. Include in writing that changes in requirements (and undiscovered requirements) w ill affect the estimate.
1d. Document and immediately communicate in writing all new and changed requirements.
When your boss's boss (inevitably) asks him what the problem is with this project taking so long, and he responds to him that you the developer (or team) "keeps finding problems and more work to do", you can at least rely on a written record of the project's changing scope.
The reason for this is that in practice I've found estimates are an indirect way to define scope.
You need to ballpark the minimal viable product in a range from under a month, a month to 3 months, 3 to 6, 6 to 1 year, over a year.
After that, its just about downscoping all the "good to haves" based on if there's time left from the desired deadline or not. As long as you delivered the "must have" in your timeframe it should be good.
Be pessimistic, don't count happy flow only. Count also meetings and other organizational slowdowns into estimation. It can be anything between 30% to 200% of needed time depending on what politics on your company is.
Break it down, and guess shortest time possible, longset time possible and them most likely time for each task. Then do (min+max+4×likely)/6 and sum them. The result will look intuitively too long, but resist temptation to shorten it.
Then resist pressure to make it smaller. If they want it faster, keep calm and ask them whether take out this or that feature. The only way to make it faster is by cutting features.
If you can’t answer right away, “I’ll get back to you” after having some time to think about what’s needed.
Then just keep that person up to date on timeline progress and it other work that’s been requested impacts that estimate.
Seriously, tomorrow morning I'm going to be in a long planning meeting where I'm going to be asked for time estimates. And this time i'm going to refuse to give any.
I've spent a fair bit of time preparing my boss, my bosses boss, and people on my team for this moment, by explaining good Agile development doesn't use time estimates. I'm going to insist that I and my fellow developers will point problems using planning poker, but the points won't correspond to any fixed time amounts.
Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant. That is why I include the "minus" bit covering this scenario where a solution is already there.
I can’t tell if you’re being serious. How do people respond to such a non-estimate?
My approach also helps start a discussion about how to reduce the size of the plus/minus bit, such as reducing scope, breaking into multiple pieces etc.
And the minus bit coming to negative time works well too. It becomes a decision about using what is already there even if not perfectly suited versus doing the new work, and how much of it to do.
In the 6 years I was there they shipped around 40 different software products, without once shipping late or a buggy product, and won dozens of industry awards.
It's not time estimations. Its how you manage your process.
What kind of software products?
Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find similar stories (or, if you're just getting started, requests of comparable scope) you worked on in the past and use those as a reference.
What happened instead: team quickly ended up equating story points to some unit of time (e.g. 1 pt = 1 day to complete). Then, for a new story, play planning poker where each developer makes estimates based on rose-tinted projections of how long they imagined it would take them to finish the job if they were working on it alone without major distractions or unanticipated complications. After everyone reveals their estimate, argue pointlessly with each other for a random amount of time. Then, once the scrum master has caught up on all the latest notifications on his or her phone, either cave to the opinion of the most belligerent member of the team or average the results.
After we got burned a few times, we added a "shit happens" cushion while still following the same basic procedure. I'd be surprised if that team didn't continue to use the same protocol to this day while gradually ballooning their cushion to the point their estimates coincided with the "double the number, shift to the next time unit" rule.
Daniel Kahneman provides a good lesson on the difference between these kind of expert-driven (for various definitions of the word "expert") estimates and the sort of historical data-based approach you suggest in Thinking Fast and Slow.
It's excerpted here:
https://www.mckinsey.com/business-functions/strategy-and-cor...
Time estimates are a fools errand, even with historical data. Historical data won't tell you if this task is really similar to that old task, or if fast dev will work on it or whether the slow dev will, or how many meetings devs will be pulled into, or who will need PTO, etc, etc.
Before I was unceremoniously shown the door, we had been discussing a rewrite of our main customer-facing website. It was basically a bank website, but for a bank that only served a few hundred clients internal to the company.
The most recent version had been written a few years ago in a Python web framework that was now defunct. This time we were going to do it right using Rails. We had been talking about a 6-8 month timeframe for release of the minimal viable version once the dev team got started. We had been talking about getting started for about 3-4 months while we got sidetracked with other spot fires, upgrades, and all the other workaday delays. The team used Agile Scrum, mostly in the ways you aren't supposed to use it (meandering voluntary standups that some developers would attend at their whim, perfunctory retrospectives in which process issues were swept under the rug, systematic disregard for the definition of done and best practices, an unhealthy focus on burndown charts). There was no special business urgency behind the upgrade as far as I knew other than the old application was getting long in the tooth and looked a bit out-of-date. It was still floating beneath the surface of the backlog when I was finally walked from the building.
A year or so later I got together for lunch with a couple friends still with the company including a project manager from the old team. I asked her how the big bank site rewrite was going.
"Oh, it's about where it was when you were still working there. Except now it's urgent."
She was not happy. The banking unit had signed up some new customers who were outside the bank and the dev team's boss said executives were eager to integrate them into the new online system. So he asked my friend, as product owner, to give him an estimate on when the new site would be ready. My friend told him she'd get back to him on it.
She logged into their project management system, filtered out all the non-essential user stories for the project, added up the sizing on the essential ones that were left, and then formed an estimate based on the team's average velocity over the last few sprints. Then, just to be safe, she removed a couple more stories that probably were essential to the MVP, added up the new total, bumped up the team's velocity a few points on the reasonable premise that they were inveterate slackers, and updated her final estimate. She then met with her boss to present her results.
She premised her estimate by outlining her methodology. She reminded him that the last version had taken over a year to complete. Then she dropped the number:
"Six months."
"Too long. We need to have it ready in three months."
My friend looked at him slack-jawed.
"I don't think that's possible." She started to review her methodology. He stopped her.
"It is possible."
"How?"
"Double the team's velocity."
This guy had been the one who had championed scrum to the company. He had hired the consulting firm that ran the three-day scrum on-site workshop that had introduced the principles of Agile Scrum in detail to the company. He had attended the workshop. We all had. Twice!
My friend found a new job and left the company within a month.
- Using points as measures of time
- Redefining "done" as something that's not really done
- Trying to ship fixed feature sets ("your commitments!") within a sprint
- Any type of time estimates.
- Burndown charts
Software Development is full of hidden pitfalls and I've found this can keep development and management teams both on the same page when unforeseen obstacles arise
I think what I intend to say with that can be, "I don't know how long it takes and it'll take more planning to figure it out, but I'm willing to participate in this conversation so that we can continue to effectively plan in the current context."
If the current context is "concrete" then you probably don't want to give a number. If the conversation is (and this was my assumption before) "here's a feature we want done but we're trying to figure out it's priority and feasibility" then giving a gut check adds value. You just need to be clear in your messaging.
And if someone uses a gut check number against you "but you said X days!" Then you need to call them on it and make sure you explained the discrepancy.
Sometimes it's an environment change. Are these consistent? Can they be modeled statistically?
Often, it's an inaccurate belief in the work to be done. Was it lack of requirements, that had to be expanded? Etc.
When I work in development, I spent up to 20% of my time on "overhead" tasks. These are of the estimate review type, not meetings. It's something a great manager will do without wasting his team's time, but as an independent, I spend a lot of time doing it myself, and it's amazing how much it helps to dedicate time and write things down.
Even then 2.5 isn't enough of a hours multiplier.
A lot of these enterprise systems have traps and tricks other developers and analysts have put in. :( :/
Arguably problematic even when the project is relatively trivial. Try it for a new "Air Traffic Control System" or new "Bank Customer Lending Management System".
It's part of being a professional to be able to give some kind of ballpark estimate.
Its your job to educate your boss and your team about this.