https://pm.stackexchange.com/questions/34768/why-are-developers-expected-to-estimate-tasks-at-all Stack Exchange Network Stack Exchange network consists of 181 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange [ ] Loading... 1. + Tour Start here for a quick overview of the site + Help Center Detailed answers to any questions you might have + Meta Discuss the workings and policies of this site + About Us Learn more about Stack Overflow the company, and our products. 2. 3. current community + Project Management help chat + Project Management Meta your communities Sign up or log in to customize your list. more stack exchange communities company blog 4. 5. Log in 6. Sign up Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up. Sign up to join this community [ano] Anybody can ask a question [ano] Anybody can answer [an] The best answers are voted up and rise to the top Project Management 1. Home 2. 1. Public 2. Questions 3. Tags 4. Users 5. Unanswered 3. Teams Stack Overflow for Teams - Start collaborating and sharing organizational knowledge. [teams-illo-free-si] Create a free Team Why Teams? 4. Teams 5. Create free Team Teams Q&A for work Connect and share knowledge within a single location that is structured and easy to search. Learn more about Teams Why are developers expected to estimate tasks at all? Ask Question Asked 3 days ago Modified today Viewed 22k times 31 This management tendency is the worst part of being a developer. Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers repeating a variation of something we've built hundreds of times before. I've been in this trap so many times: 1. Give a very wide estimate with a lot of padding 2. Get pressured to be more accurate and to bring the estimate down 3. Get pressured to work unpaid overtime to meet that estimate 4. Watch management get congratulated by upper management for running a tight ship In my ideal world, management would simply tell me which task they want me to work on next and then as it proceeds ask for a regular update of what percentage of completion it is at. It would then be the manager's responsibility to extrapolate my likely completion date, learn my accuracy over time, adjust to it and manage expectations of upper management. If developers have to be the ones carefully calculating estimates and managing expectations then there's really no purpose to middle-management. The developer might as well be speaking directly to the client if the only value added by managers is to pass estimates from one hand to the other and then brow beat developers when things don't work out. Why are things done this way when there's decades of history showing how badly it works? enter image description here * scrum * software-development * estimation Share Improve this question Follow asked Mar 23 at 13:24 Scott Bishop's user avatar Scott BishopScott Bishop 41911 gold badge22 silver badges33 bronze badges New contributor Scott Bishop is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 12 * 1 Welcome to PMSE! As you have phrased it this question is a bit too broad and opinion-based for this forum. "Why" questions won't typically get useful or interesting answers. A better question might be "What's the alternative to ...?" or "How can I deal with this situation ...?" - nvogel Mar 23 at 13:46 * 1 Assuming this isn't trolling, it's kind of on the bubble of being off-topic as we explicitly list "rants" as off-topic on PMSE. Please see our help center for more about that. Here, assuming the question remains open, you will get project management answers; if you want workplace advice on how to handle your particular situation, your question might be a better fit on The Workplace than a site about project management. - Todd A. Jacobs Mar 23 at 21:43 * 4 To me it looks like your meme sums it up - the problem isn't being asked for estimates. It's perfect reasonable to ask how long you think a task will take. It's that the estimates you give up front are being treated as deadlines, not estimates - Mick O'Hea 2 days ago * 9 Why do you give in to the pressure to work unpaid overtime? You need to refuse to do this. Your managers will continue this strategy as long as it continues to work for them. - Nacht 2 days ago * 3 Engineers have to estimate because no-one else is capable. Who do you imagine knows better? - Kingsley 2 days ago | Show 7 more comments 12 Answers 12 Sorted by: Reset to default [Highest score (default) ] 24 You Have an X/Y Problem Why are developers expected to estimate tasks at all...[when i]n my ideal world, management would simply tell me which task they want me to work on next and then as it proceeds ask for a regular update of what percentage of completion it is at. It would then be the manager's responsibility to extrapolate my likely completion date, learn my accuracy over time, adjust to it and manage expectations of upper management. Most of your question is really a rant about how things work at your workplace. Discussions about toxic workplace practices per se are out of scope for PMSE. In addition, your ideal of just plodding along and expecting the rest of the organization to adapt itself to you is unrealistic, and completely unmoored from the purpose of business, which is to make money by providing a product or service within a given schedule, scope, and cost. The company's customers also have goals, deadlines, and budgets that need to be met, so you're basically positing a world where nothing can be predicted and your personal cadence sets the pace for the entire market. That's unreasonable on its face. That said, estimating poorly or failing to use modern techniques such as batch and queue theory to manage estimates certainly leads to poor results. That's what agile frameworks address: the inaccuracy of estimates that aren't based on small, estimable, and sustainable batches that can be successfully delivered at a predictable cadence. There are even people who advocate for flow and cadence as the estimation tool (using the poorly-named #noestimates hashtag on Twitter), but there must still be bounding boxes around any project that has constraints. Your X/Y problem is that you have a problem with your company setting deadlines that you can't meet, then asking you to estimate tasks in a way that leads to inaccurate estimates and blame when deadlines are missed. That is "X". You have decided that not having deadlines or estimates is the solution to your problem, and posit this solution "Y" as the answer to the perceived process problem solely as it affects you. Unless you shift the frame to include the rest of your team, other parts of the organization, and a business perspective then you are simply venting rather than becoming part of a constructive solution. Solve for "X", Not for "Y" Implicit in your X/Y problem is a lack of effective communication with your middle management and senior leadership; possibly even within your team. You need to address the communications gap before you can do anything else. Aside from your frustration, your team and organization need to address the root cause of unmet expectations. Selling projects without sufficient controls on scope, schedule, and budget is a non-starter, so your team and the company should both understand what the constraints are. It is unlikely that it is your job to define any of these constraints, but it is certainly your responsibility to talk with your team and with line management if you are continuously working on "death march" projects. It is likely that one or more of the following need to happen: 1. There needs to be more clarity about specifications, deliverables, time frames, and scope. 2. There should be more input from your team leadership about whether the deliverables promised are reasonable within the budget, skills, and resources available to the team. 3. Your team needs to get better at decomposing work into smaller work units that can be estimated with reasonable accuracy. 4. You need to decide if the problem is the company culture or you. 5. In either case, if the process can't be fixed then you need to find a different company that's a better fit for you. The first few points are things that can be fixed in any organization once a root cause is identified and acknowledged. The last few points are really just workplace advice, which seems necessary because your current framing of the issue doesn't take anyone into account but you. If you are unhappy or a bad fit, your only realistic options are collaborate with your leadership on solving whatever underlying process problems exist or moving on to another role that makes you happier. Project management is the practice and profession of delivering a finite product or service within the constraints of scope, schedule, budget, and quality. All projects have constraints, and all successfully-managed projects have controls to manage those constraints within acceptable tolerances. While how the constraints are controlled may vary, the need for controlling project constraints will not go away. Trying to wish project management into the cornfield is not a useful endeavor. Instead, see if you can be part of the solution. If not, brush off your resume and move on. Share Improve this answer Follow answered Mar 23 at 21:41 Todd A. Jacobs's user avatar Todd A. JacobsTodd A. Jacobs 49.1k66 gold badges5656 silver badges174174 bronze badges 10 * 2 Rant or not, the OP has a genuine question. Why are developers --- professionals who study how to write software --- being given the task of estimation if the task is characteristic of another professional? - user1145880 yesterday * 1 @user253751 If you really want to nitpick, the purpose of a corporation is not to make money but to generate value. What that value means to the shareholders is conventionally money, but that difference is what allows for things like advocacy investors, non-for-profit organizations (which are technically companies), and for business to focus on longer term aims. - user1937198 yesterday * 3 There is an underlying assumption, that just because smaller units can be estimated with greater accuracy, the sum of them is a realistic and sufficiently accurate estimate. This assumes that summing them is meaningful, which may not be true depending on the what the estimates mean (if they are what the developer things is the most likely amount of time, then it is meaningless to add them), and also that there is not risk induced by the breakdown process missing entire chunks of work. Since both of these are likely, a high level estimate derived from a breakdown is often has excessive risk. - user1937198 21 hours ago * 1 @fectin And yet the lack of effective use of those techniques seems to be a common cause of the problems described. Is there anything developers can do to ensure that management use those techniques effectively? - user1937198 7 hours ago * 1 @user1937198 Sort of. The stupid answer is "Yes: become management". The less stupid answer is learn those tools and advocate for them as appropriate. Roughly: it would be bad form to just chuck code over the wall at ops, you should understand their constraints and how your products feed into them, even if you are not ops and can't do their job. You can (and ideally should) have similar understanding with every domain you touch, including management. The constraint here is that good technique comes with overhead, often lots of overhead. How much to apply is a very fuzzy optimization problem. - fectin 2 hours ago | Show 5 more comments 17 [Frame challenge] "Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers repeating a variation of something we've built hundreds of times before." (Developer and scrum master speaking) Yes, we have. We have done parts of the software dozens, if not hundreds of times. We are by definition the people best capable of estimating what it is going to take, because we have the best experience in overseeing what is required for that "simple feature request from a non-developer". This applies especially if you are working agile (you labeled your question 'scrum'), where 1. User stories are relatively short and 2. Estimates are relative to earlier stories and in arbitrary story points. Your points 2), 3) and 4) hardly apply if you work agile, at least that is what the scrum master (and product owner) are supposed to guard against. Surely, this can fail, but then you are not working agile - you are not providing a safe, reliable and trustworthy work environment, which is going to cost the developers and the company in the long run. (Actually, this is regardless of methodology, it also applies when you do 'waterfall' development). There are of course long-term goals, and is the job of the scrum master and product owner to translate to balance the velocity of the development with the goals. Which is material for a new question.... Share Improve this answer Follow answered Mar 23 at 14:41 Jan Doggen's user avatar Jan DoggenJan Doggen 48511 gold badge44 silver badges1414 bronze badges 3 * Neither agile nor scrum explicitly require the use of story points. - bdsl 2 days ago * 1 You assume the doing something is the same as estimating how long it takes. If it were true on the average, your argument would a have sound basis, but it is not true on the average. The average programmer very often fails to estimate how long it will take to do what she knows how to do. Why does this happen? Because a programmer devotes her life to study how to do it, not to estimate the time it takes. Those investing their life to estimating things are typically the statistician, the mathematician and others. (These will estimate programmer's time quite correctly, given enough data.) - user1145880 yesterday * 1 Your answer essentially says that if management is any good OPs problem shouldn't exist. That may be true but how is that supposed to be useful as an answer to OP? Management isn't always good and in his case the problem clearly does exist. - quarague 11 hours ago Add a comment | 4 Estimates are generally used for managing risk and costs and those things are legitimate concerns of management and everyone else in a commercial enterprise. Several techniques can make estimation simpler and less contentious. Continuous, iterative and incremental delivery are probably the most important and widely used tactics to control software development cost and risk. If you deliver software features every day or every week then estimating each increment is much simpler and the consequences of any delay or under-estimate are much less significant. Many development teams are expected to be responsible for their own cadence of delivery and their own estimates precisely because they are usually the people best able to do those things. Regular engagement with stakeholders and prioritization of work in terms of business value and risk are also essential. Many teams choose to make relative estimates (story points) rather than absolute ones and then measure actual productivity based on evidence rather than guesses. Check out sites like https://www.agilealliance.org/ if you want to learn more about ways of working in software development. Share Improve this answer Follow answered Mar 23 at 14:11 nvogel's user avatar nvogelnvogel 6,06111 gold badge88 silver badges2727 bronze badges 2 * As far as I can work out, in my current company (a US "Fortune 500") "story points" are used just another time currency. Like costing the project in Euros instead of Dollars. - Kingsley 2 days ago * Indeed. And, as it often happens with money, it's a subjective measure which, at the extreme, can lead to contradictory results. - user1145880 yesterday Add a comment | 2 Why are developers expected to estimate tasks? In Scrum, we don't have "tasks". We have stories. If you're estimating tasks, you might be making a mistake. Why are developers expected to estimate stories? This is a question of two parts: 1. Why must stories be estimated? 2. Why should developers be the estimators? Why must stories be estimated? Estimates are essential for sprint planning. Without them, it's hard to know how much work could be achieved in a sprint unless each story is exactly the same size (and making stories equally-sized is itself a form of estimation). Each developer's perception of whether the sprint goal could be reached will depend on their own internal assessment of the sum of all the stories. With agreed estimates of individual stories and an estimate of the team's capacity, choosing what to do can be approached more objectively (at least for the first cut; there's still a need to look at the whole and see if it makes sense). Why should developers be the estimators? Some (non-Scrum) practices have estimation done outside the team by specialised estimators. This doesn't work very will for an agile team, for several reasons: * Waiting for estimation can block a story from being Ready to begin implementation. Developers are in a position to estimate the story right when the estimate is needed. * Developers have the institutional memory of implementing similar stories in the past, so are more likely to anticipate the problems that are likely to occur, or the extra activities not specifically mentioned in the story ticket. * The discussion needed for a consensus estimate exposes deficiencies in the story description and ensures that they are resolved before work begins (e.g. the need for infrastructure changes to support the development, or a need to gather user work-flow information to guide a UI design). What is an estimate? The specific case you mention is a management anti-pattern: 1. Give a very wide estimate with a lot of padding 2. Get pressured to be more accurate and to bring the estimate down 3. Get pressured to work unpaid overtime to meet that estimate 4. Watch management get congratulated by upper management for running a tight ship One reason that we use abstract story points rather than time estimates is to avoid this culture that sees the points as predictions or forecasts rather than what they are: estimates. Another reason is that estimates can include points for complexity and for risk, rather than being based simply on time expended. This is covered well in Why use story points instead of hours for estimating? Abstract points are naturally self-adjusting. If we have consistency in what size story counts as "1 point", then it doesn't matter if that's not the same as a different team's 1-point story, as our measure of capacity is measured in "our points" and their capacity is measured in "their points". If every story in our time is "padded" to give a margin of safety, then our velocity measure will reflect that; conversely, if every story is shaved down to try to fit it into a sprint, then the velocity will reflect that instead. There's certainly a real danger in working extra time to achieve the sprint - now our velocity, and hence future capacity, takes account of that practice, and the overtime will become required in every sprint. And that's not a sustainable work practice. Much better to fail to achieve, and measure what was actually completed, in order for velocity to represent a reasonable expectation of what's a likely capacity in future sprints. How can we correct perceptions? A large part of the question seems to be predicated on management misconstruing what estimates mean. When communicating with managers, it's very easy to be misunderstood - this is often the interface where the agile world of responding to change meets the business/ financial world of having medium-long term plans for making promises to customers. In such communication, we need to regularly reinforce what an estimate means. Story estimates are by developers and for developers. As an open and transparent team, we're happy to share how we work, and show how we use our estimates to say, "we can do A or B this sprint, but not both." But we need to be clear that our commitment is to the Sprint Goal, not to individual stories, and that our estimates are quite rough categorisations (half of the time, effort will be more than anticipated and half the time it will be less - this becomes useful when stories are grouped into a sprint, because the law of averages means the aggregate total is likely to be close to the sum of the estimates). When I talk to managers, I'm always aware of their desire for predictability, so I'm always careful to distinguish between the Sprint Goal and the stories that contribute to it, and explain which parts are most likely to be incomplete when the sprint ends. Most of our sprints achieve a large part of the Goal, but often missing some of the functionality. That's why the Sprint Review exists, to assess progress so far, and work out what needs to be added to or removed from the product backlog to get to a releasable product at the right time. Any worthwhile product manager is ready to have conversations about trading scope for timescale during the product development - that's the nature of creating something new and original. Share Improve this answer Follow edited 2 days ago answered 2 days ago Toby Speight's user avatar Toby SpeightToby Speight 51733 silver badges1414 bronze badges 2 * 1 The law of large numbers only applies if a) the population is sufficiently large, otherwise outliers will dominate b) the estimates are at least mostly independent, otherwise systematic bias will skew the result and c) the estimate is in fact the expected value (mean average) of the probability distribution of time taken. If the estimate is a mode of the probability distribution, then you can not meaningfully add the estimate directly and be able to meaninfully say anything about the resulting distribution. - user1937198 yesterday * And what happens when a product manager tries to shift the blame to the developers or pressure them in order to avoid trading scope for timescale? Since that often seems to be the cause of this conversation? Or is that a question for the workplace. - user1937198 20 hours ago Add a comment | 1 Scrum should not estimate in time units, only story points, for all the reasons the other replies mention. My own rule of thumb, after 30 years as a developer (and also in life outside work), for any medium to large chunk of work (say a complete feature) is "our very best professional, honest, unpadded estimate given all we know right now - then multiply by 3". Most old hands that I have discussed this with seem to broadly agree, but might go for 2.5 times. 2.5 or 3 x seems to allow for our average levels of optimism and stuff we forget about at the beginning. This is to get stable, robust, well-written, production-ready code. Don't forget ELAPSED time would always vary (can you get meetings with the POs? How many meetings do you have? Admin? Unexpected urgent bugfixes? Can you get the testers time?) Share Improve this answer Follow answered 2 days ago kpollock's user avatar kpollockkpollock 11122 bronze badges New contributor kpollock is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 1 * although i agree +1, then one should wonder the added value of scrum, points say not much for upper management, and the whole idea becomes rather holistic despite it eats away a lot of coding time. (maybe people do it just to much) - Peter 1 hour ago Add a comment | 1 There are many possible reasons for creating estimates, including: * The process of estimating can help the developers to think through their work * There may be hard business deadlines ("release the product for Christmas") * Marketing, sales and other departments may have use of estimates ("let's delay the marketing campaign for product X as it looks like development is running late") * There may be tradeoffs in planning ("if product X takes 2 months we can look to pivot to product Y, otherwise we should hold off until next year") Having said that there are good and bad ways to do estimating. ...the only value added by managers is to pass estimates from one hand to the other and then brow beat developers when things don't work out This is an example of the bad way! A good estimating process is collaborative and it takes into account uncertainty. A common approach is to use ranges, for example a development team might estimate 2-5 months for a piece of work early on in the project. After a couple of weeks of work they feel confident to narrow that range to 2-3 months, and so on. Share Improve this answer Follow answered 2 days ago Barnaby Golden's user avatar Barnaby GoldenBarnaby Golden 19k22 gold badges1616 silver badges4949 bronze badges Add a comment | 1 This is an experience problem, not a management problem Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing before. This part is not actually true, Carpenters and Developers face about the same level of uncertainty with each project. If you've ever tried hiring a young independent carpenter, they will often way under bid the project, and have to come back asking for 2-3 times as much money to cover the unexpected materials and labor, but when you hire a carpenter with 10-30 years of experience, they can estimate a project within a 10% margin of error for actual variance, but know to build in a 50% margin of error for when the scope changes a bit, and they are on budget every time. Not because every cabinet is the same, but because they are all made up of the same basic bits and parts. These same margins of error to experience levels are seen in the software development industry, BUT software developers are on average 11 years less experienced than carpenters so we see a lot more novices and very few masters in the software world. Those experienced developers who are out there have already learned so many new languages, done so many API integrations, built so many physics models and CRUD interfaces, etc that even if they do have to do something "new" they can break it down into 20 smaller things that they already have done many times before so they know just how long it will take. Management must expect you to estimate your project Only developers know how long it takes to write software, just like only carpenters know how long it will take to make a cabinet. Yes, you in your novice ways may only be able to estimate within a 300% margin of error, but if that is how close you can get, imagine how much worse it would be if your manager had to guess? When I ask my project manager how long HE thinks a task should take, if the job is just like a previous one, then he can usually guess pretty close, but if it's not something he's seen before he's can easily be off by 2000%... and no, that is not a hyperbole. He literally does not no how a single part works where even a novice developer will have some foundational knowledge. Even a novice developer knows SOME of the processes and requirements of a new project before he starts, and that still makes a young developer's estimate the best possible guess, when no other estimate can be closer. Software development is a business. It must either make money or add a value that is worth a certain cost. While your job may be to write the software, it is your manager's job to sell a client on the idea of paying for the software. Even if you are doing inside development, your manager will still need to "sell" the value of your work to his superiors or investors... and no one buys a product without knowing what it will cost. So, if you can't provide an estimate (even a bad one) then there is no business. As for deadlines, if you can't be held accountable for your estimates, then there is also no business. Most development is a contractual agreement. When you give a manager an estimate, he has to turn that into a bid to sell your time to the client. His job is not just to say, "this is 1000 hours of work". His job is to talk to the client, get a feel for them, and decide if he can get away with asking for $100,000 or $150,000. He has to consider how much residual income this client is worth. He has to consider if it's worth risking the company's reputation asking for add-on costs if things go over budget, he has to consider if he should offer the client a payment plan, he has to consider dollar per hour how much each person working on the project costs the company. He has to consider how much he has to pay you to NOT work if too many bids fall through. Even if you are doing Agile development, these are still the kinds of numbers he has to discuss with clients. Agile is a method for organizing development, not a substitution for responsible financing. So, no he's not just getting high-fives for projects taking how long you said they should take, he's getting high-fives for all sorts of responsibilities and skills that you don't even need to think about that have to come together just right to keep the company going. Yes, he needs your expertise where he needs it, but he has a whole other litany of jobs to worry about that you as a developer don't see. The real problem in the development industry Going back to the Carpenter problem, Carpenter's solved this issue centuries ago when they developed the guild system of management. In guild work, you have apprentices, journeymen, and masters. A young and inexperienced craftsman should never work without the oversight of a master, and a moderately experience craftsman should only work independently on "basic" things, but there are just too few master developers to go around and no unified system for licensing masters to make sure that they are as good and experienced as they should be. Some larger firms actually have partially adopted this system though. We generally call them Intro, Junior, and Senior or Tier I, II, & III developers. If you work in such a firm, then the Senior Developer is usually the one who writes the estimates, but the issue is that most of these companies have only half adopted the guild system. A person can be "senior" in title, but there are no quality controls to make sure that he actually has the skills that he should have; so, he may not be qualified to write estimates for apprentices (or even himself for that matter.) Give the industry another 10-20 years to mature, and you will probably see it get to be almost identical to the carpentry industry... for now though, companies are just doing the best they can with the experience that is available. Share Improve this answer Follow edited 2 days ago answered 2 days ago Nosajimiki's user avatar NosajimikiNosajimiki 11144 bronze badges New contributor Nosajimiki is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 2 * 2 Regarding the experiance problem. One issue in software is that more than any other industry, software developers work with abstractions. What this means in practice is the industry is never standing still. As soon as there is a reasonable consensus on a process for solving some specific problem, someone will be working on trying to automate the solving of that problem. More than anything else, this attitude is what has a) enabled software to do so much and b) caused the industry to get stuck in a state of perpetual inexperience. - user1937198 yesterday * So management needs a way to make informed risk decisions about business choices based on how long things take. Is it really the developers responsibility to ensure that that risk choice was the correct call? Or is it the developers responsibility purely to provide information and make a reasonable effort at building the system. It seems like a big part of this issue is managers take the estimates, and make decision of how risk averse to be, but its often the developers who are pressured to take the consequences of that decision, because 'the estimates where wrong'. - user1937198 20 hours ago Add a comment | 1 Why are developers expected to estimate tasks at all? Because if we didn't, who would? Do you want a project manager (who, as you've no doubt experienced by now, knows nothing about the realities of developing software) estimating in advance how long a programming task is going to take? Such that you then have to try to meet that schedule? I've had that happen to me a couple of times, and it ain't pretty. Ill-informed managers really do have a propensity of imagining that writing code is like making cabinets, churning out minor variations of something that's been built hundreds of times before. Yes, trying to estimate an unknown task is hard, and it's no fun, and there are some pretty bad consequences of getting it wrong, in either direction. I get it: I'm a developer, too. (Normally I hang out over on Stack Overflow. I signed up for an account here on pm.stackexchange just so I could give you this answer, so that you can hopefully take me seriously, even if you're suspicious that all the regulars here are just a bunch of project managers who don't get it, after drinking too much kool-aid.) The thing is, estimating how long a new task is going to take is a skill you can develop, like any other. If you get good at it (demonstrably good at it, by having your actuals track your estimates pretty well), people will start trusting your estimates. They won't engage in the fallacious task of trying to bargain you down, and when you're faced with a really uncertain task, that you can't give a good estimate for because the task truly is unknown, they'll listen to you and work with you on that basis, too. But, when you think about it, most tasks are not "truly unknown". They're like tasks you've done before, in one respect or another. In fact, in all but the newest startups, many if not most tasks are incremental modifications to code you've already got. I pride myself on my estimates, and the people I work with love them, because they are generally accurate. (It helps that I've been doing this for a long time, such that I've got a pretty good intuitive feel for it.) My boss doesn't even multiply my estimates by 2 any more. I don't know the environment where you work, but I'm going to go out on a limb and say that the other engineers in your organization (the EE's and ME's and whatever) are not designing knock-off cabinets, either. They're designing brand-new widgets, too -- after all, if the widgets weren't brand-new, they wouldn't need designing! I know (believe me, I know) how wonderful it would be if everyone could just go away and let us polish our code to perfection, no matter how long it takes. (That's exactly how I run my personal projects.) But, you know, seriously: no matter how much you hate schedules and deadlines and Gantt charts, a real company (the kind that can pay you money) has to have them! How else can they know whether the project's delivery schedule will meet the expectations of the salesman and accountants -- and customers! -- who are depending on it? How else will they know how many engineers to assign to the project? How else will they know -- if it comes to that -- that the project is impossible, and needs to be canceled now, before they waste any more money on it? Don't say, "But Software is different!" That's a prima donna attitude, that won't win you any friends. Software is fundamentally different in some interesting respects: it's infinitely malleable, its manufacturing cost is near zero, the lead time for raw materials (1's and 0's) is zero, and (because it's infinitely malleable) the requirements are always changing at the last minute. But my advice is to hold the "Software is different!" card close to your chest, and play it at the end, when people are asking for last-minute requirement changes to counteract problems that have cropped up in the other disciplines that aren't so malleable. That way you can be a hero, and get some slack for the fact that the last-minute requirement changes are going to blow out your schedule (again). But don't try to play that card up front: it just makes you look like a whiner. [Disclaimer for all the regulars here on pm.stackexchange: Apologies for the newbie post, which is written in total ignorance of this community's penchants and proclivities. And I hope no one felt I was saying that you were a kool-aid-drinking project manager who doesn't get the realities of software development, because although I did use some of those words, that's certainly not what I was trying to say.] Share Improve this answer Follow edited yesterday answered yesterday Steve Summit's user avatar Steve SummitSteve Summit 11133 bronze badges New contributor Steve Summit is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. Add a comment | 1 Why? The why, as stated by others, is simply that the top level wants to know "how long" and that has to bubble all the way down to asking the person that's going to do the work. The frustration "solution" The actual problem is your frustration, and the answer to that is that you need to partially skip #2. Don't succumb to pressure by just lowering your estimates. With experience, you may get better at estimating (I've been doing this for 30 years, and I'm not sure that I've gotten noticeably better, but I also have no sense of time in the first place) but you don't do yourself any favors by randomly lowering. If you learn as you get into a problem that it can be done faster, fine. But you may also learn that it's going to take longer and need to adjust your estimate up. Scrum reality To the others talking about story points and that estimates aren't supposed to be deadlines, the reality is that that isn't how it works in a lot of places. I've never been in a scrum team that actually follows that "by the book". Yeah, we use story points, and they are relative to "other work". Ideally, it's supposed to be that during initial stages, you've found the lowest effort item in the project, assigned it a 1 and everything else is relative to that, or something. But I've never been a part of a team that actually does that step, and people jump around teams or even companies so much that they have no idea where the "1" is at or how much effort it took anyway. So in all of our teams, the defacto baseline is "some imaginary story someone did at some point in the past that took exactly 1 day". So story points are days. On top of that, management one level up wants actual numbers anyway, so we estimate stories with story points and then are required to add "remaining hours" to each task within the story. I multiply story points by 8, subtract the "standard" tasks, like "get code ready for deployment" and whatever is left goes on the coding and testing tasks. Ultimately, this feeds back into the why. Regardless of what your team or scrum master or product owner think about the estimates, some level up there somewhere wants a deadline. TLDR So, long story short, we are asked to estimate because that's who should be estimating. But it's up to you to 1. make sure your estimates are realistic 2. be conscientious about trying to meet that estimate, and 3. to also try to make sure you are on a team that realizes and accepts that actual time may go over or under that estimate. Often the only way to do #3 is to continue with #1 and #2 until they accept it or fire you, or you find a new job. But adjusting your estimates down for management is never going to get you #3, and every time you work your butt off to meet the new goal, it implies to them that you weren't doing #1 and #2. Share Improve this answer Follow answered yesterday user34314's user avatar user34314user34314 11111 bronze badge New contributor user34314 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. Add a comment | 0 There is no history of how badly estimates work. Further, how your management or your customers treat your estimates is not a sign of how the estimating process is worthless but a sign of poor management. Estimates are mandatory, despite the no estimate crowd that seems to be brewing in the software industry. No customer will ever buy something with a blank check. Finally, you have to estimate in order to measure progress. It's the fourth of the five immutable project management laws. Every estimate or planning value you choose, whether you're doing carpentry or true first of its kind work, that planning values lives in a range of probabilistic results. It's not about getting it 100% right. It's about choosing a planning value that has the appropriate amount of risk and then measuring performance so you can predict the variance you will end up with. EDIT to answer Comment: Firstly, true FOAKs are quite exceptional. If it is a FOAK for your team, then you need to find different talent. If that's not possible, then you need to learn how to manage up. If you have a ton of uncertainty around an estimate, then you need to say that to management. If all you feel is pressure to commit to something you cannot confidently take on, and then blame you for failing to meet those deadlines despite what you told them, then put your resume on the street. You work for idiots. But you cannot find something magical about an estimating process if you have that kind of management. Nothing will work. Solve for the right problem. Share Improve this answer Follow edited 2 days ago answered Mar 23 at 22:27 David Espina's user avatar David EspinaDavid Espina 37k44 gold badges3333 silver badges9191 bronze badges 5 * And what do you do if you do not think you can give a value with an appropriate amount of risk? Part of the problem here seems to stem from failure to take into account when only a large amount of risk on the estimate can be given, or worse the team does not yet have sufficient competency to qualify the risk in their estimate? - user1937198 2 days ago * @user1937198 Three techniques I know of: If you know what needs to be done but the story's too big to estimate all in one go, it should be broken it down into smaller, individually testable stories. If you broadly understand the work, but there are risks, estimate for what you believe to be the worst-case scenario (e.g., we have to rewrite the whole workflow through component X to make feature Y work) and hope it doesn't come to that. If you lack enough information to even take a decent guess at the size, you need to execute a spike story first to figure out how you're going to implement it. - Corrodias 2 days ago * 1 @Corrodias And when management are asking you to come up with an estimate in less time than is needed for work breakdown/spike? Especially if they are asking estimates for larger pieces of work. And also, how do you manage working out how the risk builds up from multiple different estimates. Because everytime you combine estimates that adds risk. - user1937198 2 days ago * "FOAK" is probably first-of-a-kind. Or maybe FOIK ( first-of-its-kind) or OOAK (one of a kind). - Peter Mortensen 2 days ago * @user1937198 You should communicate that you cannot reasonably estimate it without doing more research. If they insist that you make up a number, right now, damn the consequences, then you can either take a wild guess or be fired, I suppose. That's their prerogative. There's no law that managers have to be good at their jobs, anywhere that I know of. It's ugly, but if you can't, then you can't. - Corrodias 17 hours ago Add a comment | 0 It seems that none of the answers so far identify that doing one thing is a problem P and estimating how long it takes to do that thing is another problem, Q, and P =/= Q. We may assert, therefore, that management asking developers to estimate themselves are assuming that such activity belongs to the same metier as software development. A thesis that could be investigated would be whether developers estimating from intuition (which is very often what they they do) score higher, the same, or lower than a lay person estimating by using a naive approach. How does the lay person with the naive approach compare against the developer using his typical "method"? (This very question is more characteristic of what time of field?) Share Improve this answer Follow edited yesterday answered yesterday user1145880's user avatar user1145880user1145880 10111 bronze badge New contributor user1145880 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 1 * As it's currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. - Community Bot 16 hours ago Add a comment | -1 You don't have to estimate. Story count turns out to be a better metric. Search for #noestimates, Woodie Zuill , Vasco Duarte. I'm pretty annoyed by 1. The lack of mention here 2. The single mention seems to discredit it. Please educate yourself on no estimates before you trash talk it. It works and works better than spending all that time and money on estimates that don't work. Share Improve this answer Follow edited 5 hours ago answered 5 hours ago Duane's user avatar DuaneDuane 111 bronze badge New contributor Duane is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 1 * As currently written, this answer is unclear. It would be beneficial to explain the tradeoffs of noestimates, and how the long term forecasting issue is addressed to allow the business to make appropriate risk decisions. - user1937198 3 hours ago Add a comment | Your Answer Scott Bishop is a new contributor. Be nice, and check out our Code of Conduct. [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] Thanks for contributing an answer to Project Management Stack Exchange! * Please be sure to answer the question. Provide details and share your research! But avoid ... * Asking for help, clarification, or responding to other answers. * Making statements based on opinion; back them up with references or personal experience. To learn more, see our tips on writing great answers. Draft saved Draft discarded [ ] Sign up or log in Sign up using Google Sign up using Facebook Sign up using Email and Password Submit Post as a guest Name [ ] Email Required, but never shown [ ] Post as a guest Name [ ] Email Required, but never shown [ ] Post Your Answer Discard By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy Not the answer you're looking for? Browse other questions tagged * scrum * software-development * estimation or ask your own question. Linked 163 Why use story points instead of hours for estimating? Related 3 creating a PM system and what's best way to get developers to estimate? 1 Project Management Gantt Tool makes All Tasks Concurrent 7 Does the team estimate time for tasks or stories or both? 6 Small firm with 4 developers and 2 project managers in need of some guidance for project workflow 21 Why are estimates treated like deadlines? 19 What are developers expected to do during testing in the latter half of each Sprint? 7 Developers don't like to estimate. What can I do to improve the process? 2 Should I estimate repeating tasks (besides Stories and Bugs)? 12 If we can't finish all tasks, does this mean we are doing Scrum wrong? 2 Scrum: What do Developers do after all tickets have made it to QA? Hot Network Questions * Can stars be born giants? * Purpose of 1 kO resistor in parallel with load at output of op-amp * Can Titania, Voice of Gaea be melded on the same turn that she is brought into play with Oath of Druids? * Hydraulic disc brakes: is 4 pistons front/2 pistons rear a "better" combination? * If a meeting in 1900 occurred in a Masonic Hall, does that imply it was a meeting of Freemasons? * When did the expansion, "hustle culture", emerge? * How can I finish the frame of a hidden door without using trim? * Confused regarding the wavelength of standing waves and their relation with wave speed * "Be Perfect" (Mt. 5:48) - a stand-alone commandment, a summary of the Sermon on the Mount, or the conclusion of the teaching on loving one's enemy? * What can be done to mitigate rental income tax liability once depreciation is fully exhausted? * How to Create Multiple Files (different names) to a specific directories at Once in a Linux Terminal * What is a Mars 5-sol orbit? * What is the legal distinction between watching a YouTube video in a browser and downloading it for personal use? * What is a Stochastic Process? * Could it be possible to detect planets from stars that went supernova through the resulting nebula shape? * Types of Clause * How do I insert this url in a footnote * Can you charge a capacitor with only voltage (without current)? If No, then how does a capacitor correct power factor? * Source for the four questions you're asked at the gates * Why is it generally important to be consistent with the tone and style of writing? * BSD license attribution * To which space does the derivative of a function in Fock space belong? * Looking for title of future ice age book from before 1980 * Is it Ri Ben Ren or nihonzin? more hot questions Question feed Subscribe to RSS Question feed To subscribe to this RSS feed, copy and paste this URL into your RSS reader. [https://pm.stackexch] * Project Management * Tour * Help * Chat * Contact * Feedback Company * Stack Overflow * Teams * Advertising * Collectives * Talent * About * Press * Legal * Privacy Policy * Terms of Service * Cookie Settings * Cookie Policy Stack Exchange Network * Technology * Culture & recreation * Life & arts * Science * Professional * Business * API * Data * Blog * Facebook * Twitter * LinkedIn * Instagram Site design / logo (c) 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA. rev 2023.3.24.43346 Your privacy By clicking "Accept all cookies", you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy. Accept all cookies Necessary cookies only Customize settings