Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you do estimates in 2021?
127 points by buttonsmasher on Sept 26, 2021 | hide | past | favorite | 98 comments
For context, I am a manager at a medium sized enterprise software company, I worked as an engineer for 10+ years and took over managing the team. We have 80+ engineers in the entire org. broken down into smaller teams of 5-10. My team specifically has about 15 engineers broken down into teams of 3-5. We have a very challenging roadmap and often we end up delivering 20-30% of what's planned for the year. One thing that's often asked is how do we estimate, how do we predict when some feature will be done. We are close to 20+ years into the usage of Agile methods, there is the school of thought who prefer to use time based estimates, some try story points and then there is the No Estimates movement. I am trying to see what's considered as a best practice to start something for the team in 2021.



The below is a joke, but sadly it is representative of most teams I have worked on.

If it's like anything that most managers do, you have the team come up with estimates, have some meetings to see if you missed anything, discover that you did, then create a schedule, remembering to add slack time for unforeseen interruptions due to people getting sick, customer issues, etc.

Then you see that the schedule is too long. Slowly but surely browbeat the team into saying "yes" to the question "do you think this can be done faster" on every task. Do this some more when someone from sales asks if something can be delivered in a particular quarter.

Get very stressed out when the real project deliverable dates align much more closely with the original estimate than the unrealistic one. Micromanage your people and stress them out. Keep freaking out as you miss every deadline in the "pipe dream" plan.

Deliver the project with a mild slip compared to the original plan (because you missed something major in the original planning as it is impossible to foresee everything). Use the twice-too-short plan as your metric though. Still, the product is awesome, so give your people a pat on the back.

Hold a "lessons learned" presentation swearing to never do this again. Speak at length about how critical good estimation is. Go on to repeat the very same exercise for your next project.

Just had an idea: maybe keep the version of the timeline from before you haggle down the dates and keep checking which one matches reality better? You don't have to tell the developers that you are doing it if you believe us programmers need some flogging to keep us coding.


As a dev who has quite some freedom managing himself, I learned to multiply my own estimates by about 2-2.5.

If I had a bad case of managers, I would probably multiply by four.


I remember one of Akin's Laws of Spacecraft Design being something like: take your original estimates, multiply the time by π and shift the decimal on cost one place to the right.


https://spacecraft.ssl.umd.edu/akins_laws.html

My favorite might be 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.


Also related: always multiply your estimates by pi https://web.archive.org/web/20170603123809/http://www.tuicoo...


I personally multiply by 3 for any process which isn't almost entirely automation.


3x fits pretty much every engineering project I've worked on.


Same. And this is also what I teach junior engineers to do. If there are any unknowns, double it to 6x. No one will be upset if you deliver early.


3 is about right.

What happens is that the difference between the estimate that management will psychologically accept to begin the project (and then commit to due to sunk cost fallacy) and the actual schedule is about a factor of 3.


You forget to factor in your own bias.

https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg


There's a paper that gives an exact number: 1.7x. This is the average time it goes over estimates, for code and writing tasks. The other numbers seem better, but you should not go below 1.7.


electrical engineer + IT dev now here - literally every project I've taken part was 3x the estimate.


I think I need to talk to my therapist after reading this


I think the only thing you missed was that the original estimate also included more FTEs, but then they cut those too. This whole chain of reality was a big part of why I eventually decided I had to get out of tech. The people doing the work can often articulate the work and provide solid estimates to the work, but they will get chewed up by people with other agendas.


Or a variation on the theme: "we know this schedule is aggressive, but we have open reqs to hire another 3 engineers"... who of course never materialize.


Very curious to know how did you get out and what you do for a living now as I’m looking to save myself as well.


Another post also asked but I am interested too: what have you moved on to?


Where is the joke? This sound like SOP.


I can't stress this enough how accurate this is in my current company.


Don't estimate. They don't matter and nobody cares about them anyway. If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.

If you're a company that plans far in advance, the same is true. You'll demand the work you wanted is done at a given date, again regardless of how difficult it was.

At my company, we have a well maintained backlog of work. We pick dates in the future to check in on what got done in between check ins. The product manager can (re)prioritize work as needed. We pull from the top. If there's a surprise deadline it gets brought up to everyone and then put at the top of the queue, sometimes over currently in-progress tasks.

You cannot bend the realities of time and complexity. If something is hard, an estimate doesn't make it easier. A hard delivery date also doesn't bring predictability. Ultimately, with or without estimates, you'll get what you get. If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up. If every team is working optimally (they're not), hire.

I'll also add, the time it takes to prepare an estimate of any value is probably 10x what anybody asking you to estimate something is willing to provide. You're being asked to spit out a number to fit an existing narrative. If you wanted to estimate a unit of work with any amount of legitimacy, you'd need hours/days/weeks (depending on SOW). These companies scheduling weekly estimation meetings that last an hour and are bullshit scrum cards don't matter and aren't interested in being even close to correct.


> Don't estimate. They don't matter and nobody cares about them anyway.

Except for when potential clients ask your company: "How much implementing a system to do X would cost?"

If your company attempts to calculate this based on how many people would be needed to cover the scope and what the technical complexity of the implementation would be like, then you need to give an answer as a developer, so that the sales department can do some ballpark calculations and give a response to the clients. Especially when numerous other companies within the industry are also attempting to answer that same question.

The processes and methods vary, of course, some use historical data from other projects, some use methodologies like COCOMO, others don't even ask their technical people and try to squeeze as much money from these potential clients as possible, but in the end, someone somewhere cares about the total time the project could take, ahead of time.

It doesn't matter that it's almost impossible to give accurate estimates due to the nature of development (e.g. an everchanging environment with bunches of different technologies that evolve and die, as opposed to a production line of widgets) and it doesn't matter that these requirements are probably inaccurate, that they will change, that there will be scope creep and numerous other difficulties (various development decisions that will impact the project long term, many restrictions and requirements that are dependent on the environments that the clients have).

In the end, i dislike estimation, clients probably don't care about any of the above and want them anyways, which leads to the development methodologies remaining "agile" in name only and estimates end up being expressed in days rather than an abstract number representation of complexity when compared to other similar tasks in that particular project.


> Except for when potential clients ask your company: "How much would implementing a system to do X cost?"

And what do estimates provide here, that sales just picking a number doesn't? Estimates are made up numbers. They're estimates.

Also this line that you omitted answers your question more directly:

> If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.


> And what do estimates provide here, that sales just picking a number doesn't?

Example #1:

  - a company in the industry asks your company to implement $FOO, they want to know how much it'd cost
  - the sales people talk to the engineers, who come up with a certain amount of time it could take
  - the sales people turn this into a monetary figure of $X
  - a contract is made, the project proceeds to be developed, probably with some delays and overruns, but works in the end and is profitable
Example #2:

  - a different company in the industry asks your company to implement $BAR, they want to know how much it'd cost
  - the sales people decide that $BAR is similar enough to $FOO and that there's no need to consult the engineers, they just give a similar estimate
  - turns out that the project MUST be made for JavaEE, since that's what the company is using
  - turns out that the project MUST work on Java 8, since that's what the company is using
  - turns out that the project MUST use Oracle DB, which then requires licensing and particular setup for the environments
  - turns out that the project MUST use GlassFish and instructions must be written for it, because deployments will be done by the clients' Ops person
  - turns out that the project MUST be deployed as a .war file, because of the above
  - turns out that the project MUST work in RHEL 7 because that's what the clients are using, same situation as with Oracle
  - turns out that the project MUST have both a test coverage of >80% and integration tests, which weren't a consideration in the previous project
  - turns out that the project MUST support IE because for some reason that's what the employees of the client company are using
  - as a consequence, the technical implementation takes about 200-300% longer than previously estimated
  - the project is no longer profitable and is a net loss for the company
Example #3:

  - there's yet another company that asks for $BAZ, they want to know how much it'd cost
  - the sales people had a really bad time with that last project, so this time they decide to increase the estimate
  - turns out that this new project does not have any of those constraints
  - because of this, the estimate is really large
  - the company looks at this and decides to go with your competitor instead
  - your company loses out on the opportunity of working on the project entirely
In the example #1, the ballpark figures were accurate enough for the project to be done in a profitable manner. In example #2, there were factors that weren't considered and would result in either contractual penalties, the clients deciding to break the contract because you can't deliver on time, or to take you to court. In example #3, past data was used in an inaccurate way due to not being applicable to the constraints at hand (or lack thereof).

Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.


Some sales people work out how much the client is willing to pay, and that's the price. The deliverables are squeezed in to that price at a later date, by cutting corners if necessary - I think it's quite an effective way for companies to make money.


Make money? Sure.

Deliver working software? Perhaps.

Deliver quality software? Almost certainly not.

Now, whether people actually want quality software, given that its development would take a lot of time, is debatable. Many times being the first to market is good enough, though saying that leaves a sour taste in my mouth as an engineer.


> Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.

Yeah this, to me, totally invalidated the rest of your example. Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all. It is not clear to me that any "estimation" changed this calculus at all.


> Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all.

Except that there are penalty mechanisms in place to prevent this from happening.

So your company was slow to deliver the product and needs more time? You better be prepared to work for your own resources, otherwise the escrow won't get released, as per the contract.

Or perhaps you cannot finish it at all? Get ready to either not receive a large portion of the money at all, or to be sued outright. For an example, see here: https://www.consulting.us/news/2197/accenture-sued-for-32-mi...

Disclaimer: i have nothing to do with Accenture or consulting in the US, though consulting, government contracts etc. all share certain similarities and bureaucratic processes in most countries that don't always align with the realities of actually developing software.

If you can, steer clear of all of that and instead work for a technology oriented company that develops a product that they also sell themselves. One, in which the developers are viewed as a profit center, instead of a cog in a ROI generation machine. Ideally, an engineering led company.


Example #4

  A CTO of an American company, to get a bonus of $7 million, lays off a ton-load of the company’s CRM people who knew how 20 years of architecture duct tape that ran the company was strung together.

  CTO then proceeds to hire a cheap, offshoring body shop to design the company’s new website, which talks to the CRM. However, there’s no more CRM people at the American company because they’ve all gotten laid off and the offshore web contractors also now have to become customized CRM experts, which is insane scope creep.

  The outsourcing company can’t deliver and litigation is sought, while the US company takes zero responsibility for the fact that all the CRM people were let go and there’s no chance in hell that web developers at the outsourcing can ever learn the highly customized domain-specific logic that fast that extensively. Meanwhile, CTO gets fired and a severance of $1 million for all the extreme damage he did to the company.
And that’s Hertz vs Accenture, or at least how I heard it to be.


> Don't estimate. They don't matter and nobody cares about them anyway.

This only works for some projects. For example if your MVP or go/no go prototype costs $5MM (which a hardware or life science product easily could) you really need to know if it will be 5 or 10.

I ran a company which always quoted 3X fixed price what we thought the project would really cost, even if things turned out to go wrong. Typically we made the (promised) schedule, and when not (luckily didn’t happen too often) the customer would be able to tell pretty much as soon as we could tell, and together we dealt with it.

But as for the cost: most projects were extremely profitable but sometimes we would lose hundreds of thousands on them. That’s why we charged such a premium: we absorbed the financial risk (not that we ever told the customers our internal cost estimate — none of their business!)


Hardware and life science projects usually have more time to research and prepare than the hour of weekly estimation provided by silly agile orgs.

Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter?

As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.


> As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.

Knowing how far you'll get might affect what you prioritize, no?


> Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter?

Most of the time, in my experience. At a bigger company that may not matter so much but at a startup it can be fatal.


When prioritizing, it's not always obvious which items are big vs small. How do you provide that feedback to PM during prioritization?

Sometimes implementing what should be a simple feature requires a month of refactoring some old technical debt. And sometimes what seems like a very complex feature is actually just a matter of enabling a flag on some third party component you're already using.

All is us have likely experienced "why is x taking so long?? Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?


I think that last paragraph has a clue as to the problem and solution. Those questions all are assuming someone other than the devs are responsible for deciding things. If the devs are making those calls, they won't wonder why things are taking so long or what could have been simple. PMs should help act as an intermediary with the customer and convey that domain information to the devs but shouldn't have any real say over the roadmap or features as they don't have the knowledge or experience to make those calls.


> When prioritizing, it's not always obvious which items are big vs small.

Why does the size of the work that needs to get done matter? If you need it you need it. If you don't, you don't. If you want a fast fix, note it. Speak in outcomes. "The lowest amount of work possible to get us ________"

> All is us have likely experienced "why is x taking so long??

I wouldn't work with a PM that disrespected me like that.

> Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

This isn't prioritization, it's a PM making ill-informed judgements on dev work. Don't have your PMs do that. Product people can define priority, scope, etc. If your PM isn't prioritizing something because they think it takes a long time, they do not understand their role.


> Why does the size of the work that needs to get done matter? If you need it you need it.

Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.


> Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract

As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.


But not trying something very unlikely to succeed sounds valuable to me. Why waste 2 months of engineering time if your engineering team is convinced it will take at least 6 months?


> If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up

Exactly, the answers might surprise you


A few related threads from the past year or so:

Defense against the dark art of estimation bargaining (2014) - https://news.ycombinator.com/item?id=28208859 - Aug 2021 (71 comments)

Guide to Software Project Estimation - https://news.ycombinator.com/item?id=28047973 - Aug 2021 (40 comments)

Software estimation is hard – do it anyway - https://news.ycombinator.com/item?id=27687265 - June 2021 (230 comments)

How I started believing in Cycle Time over Estimation - https://news.ycombinator.com/item?id=26165779 - Feb 2021 (34 comments)

Software effort estimation is mostly fake research - https://news.ycombinator.com/item?id=25825244 - Jan 2021 (308 comments)

Back of the envelope estimation hacks - https://news.ycombinator.com/item?id=23278405 - May 2020 (77 comments)

(obviously there have been many more, going back further)


I use Halo difficulty levels: easy, normal, heroic, legendary. They're basically t shirt sizes but I think they better convey the size of work to be done. From there, you haggle around how many you can do in a given sprint, knowing that a legendary one is basically high risk and could take more than one sprint.

For level of urgency, I have another system for that, using Cold stone creamery sizes: Gotta have it (must ship this sprint), love it (should ship this sprint), like it (stretch goal). Anything that doesn't get done gets bumped to the next level of urgency for the next sprint.


I like this system and most companies I've worked for use a variation of it (with different names). The OP is probably suffering from undersized tickets, adding tickets after the fact, and marking everything urgent.


Your urgency system is very similar to the MoSCOW method, if anyone's looking for some historical legitimacy for a (very valid) prioritization technique:

https://en.wikipedia.org/wiki/MoSCoW_method


I use a statistical model, where each task gets a "best case" and "worst case" estimate; those estimates are used to create a log normal distribution, and the project is simulated as the sum of those distributions plus sick days, social loafing, etc.

I use that method for all my consulting estimates, and it has been very reliable for me; no crunch time, and I often come in under time. I've also made a tool that does the math so my clients and other people can continue to use the same process without me.

[1] https://quotes.vistimo.com/


This looks wonderful, thank you! I think statistical estimation of large projects is an overlooked area.


I would prefer not to estimate at all because estimates are, in the Lean sense, waste: i.e., something that your customers don’t value.

Unfortunately, that argument never worked with my managers at project budgeting time.

As a result, because I was really bad at estimating, I spent a day teaching myself function point (FP) estimation. I also found a chart detailing how many hours of effort an “average” organization required to build projects of varying FP sizes. This meant that it was easy to make a simple spreadsheet using the chart data and Excel’s FORECAST function to generate estimates.

With that approach, my subsequent projects were always within 10% of the estimate, which is much better than my pre-function-point estimates. Combining that approach with the Agile idea of working on the most important features first meant that my projects were largely free of drama come deadline time.


The highest performing teams I have been a part of did not regularly do estimates for planned work. That may be the best practice for 2021.

If we had to absolutely deliver by a fixed date - a rarity - we broke the task down in parts that could be estimated, identified the dependencies between tasks, and kept management informed if those dates could slip.

This lightweight process worked pretty well if we had to implement it. There was a lot of trust put in the engineers.


Can you tell more? I would be interested how you can get management to let go of regular estimations, and how you still delivered.


Upper management should be ok with estimates expressed in sprints.

As long as your team manages to finish sprints, it doesn’t matter how you are estimating (or not) the tasks inside of a sprint.

Sprint tasks are for internal (team) use only, including the management inside the team. But people outside (and up) the team just need your deadline commitment.


> I would be interested how you can get management to let go of regular estimations,

They have to convince themselves.


If they pay a lot of money per hour, they basically convince themselves of whatever it is they're paying for.


When debugging an agile process I'd distinguish two kinds of "out of control" conditions:

(1) Individual sprints more-or-less hit their goals. Maybe you do 80% of what you expected to do consistently, but there never seems to be a last sprint. (e.g. new requirements keep coming up, new problems get discovered, etc.)

(2) Each sprint is a disaster. You deliver 20 or 30% of what you expected in the sprint.

If you ask the people in the team and other stakeholders you might even find that some believe (1) is the case, others believe (2) is the case.

I would look the following mismatch: The conventional sprint planning process assumes the work is a big bucket of punchclock time where there are no dependency orders, one team member can do the work of another team member, etc.

In some cases this is close to the truth, in other cases it is nowhere near the truth.

For instance if you plan to have work implemented and tested within the boundary of one sprint there is a point at which the work is sent over the wall to the tester. I worked on one project for which each iteration contained a machine learning model that took two days to train (most of this process happened outside "punchclock time") If everything went right you could start two days before the end of the sprint and have a model, but often things didn't go right and if you really wanted the sprint to succeed you would want to start training the model as early as you can, maybe even over the first weekend.

If wallclock time and temporal dependencies are the real issue you have to address that.


We do No Estimates because we just stopped somehow to estimate tickets some years ago and it didn’t bothered us. We have no real value of what is the time to do a ticket but we know how many of them our team can achieve during a sprint and that’s enough.

We naturally learned to slice « too big » tickets and we roughly define « too big » by « I’ll probably struggle on this ».

It’s far from perfect, not really better but absolutely not worse than when we did estimates and we are able to achieve our goals, which is what matters.


I've ran a software agency for 8 years, and whats worked best for us is using PERT (Program Evaluation and Review Technique) estimation, or 3-point estimation, where you individually estimate optimistic, pessimistic, and most likely cases - to then calculate a weighted average.

Whilst I've found this can help weed out biases and gut feelings - I still add a multiplier that i've refined over the years. Basically chaos allowance, that aims to take into account the things you can't possible take into account yet.

I think me the most common cause of estimation issues arises more from unclear acceptance criteria, rather than calculation issues, so i've learn to work with my clients to capture a huge level of detail in the user story acceptance criteria (kind of anti-agile I know), and only then do a fine grained estimate for every story. This undoubtedly takes a lot of time, but in the end it's what works well on the majority of my projects (i generally do this in a paid scoping phase).


Full disclosure; I am not a manager of anyone nor do I work in a software company. However, I work in an industry where things need to be timed out pretty well and I have to constantly provide an answer to my bosses and colleagues of the question "When do you expect to be able to do X?".

From my perspective it involves two things.

First, it is about applying the experience of similar situations to the future. I can't very well tell my coworkers "I don't know" because the work that they do depends on me getting my stuff done, especially in a timely manner. Thus, I have to draw on previous experience to say, "Well, this (or something like this) took me two weeks to get done last time so it will likely take me a similar amount of time this go round."

The second part of that is being open with expectations. Being up front with my coworkers involves me telling them that while I think this will take X amount of time, these are the complications I am facing that could have an impact on my ability to deliver in the provided time frame.

Ultimately, by applying a combination of those two things I have been able to build a good relationship with those I work with when it comes to providing estimates and expectations for delivery. Honestly, not sure how this will apply to software engineering or if it is even translatable at all, but that's my two cents.


This sounds like good advice, and that level of communication can certainly be missing sometimes.

Quite a few software projects though are one off custom jobs where the requirements have never been implemented before (sometimes anywhere) and it does make estimating based on past performance pretty difficult. It's also notoriously hard to predict all the problems you might come across ahead of time, especially if you aren't familiar with the specifics of the code you will need to integrate with (maybe you could consider that like quoting to refurbish an old house before you've looked inside it and seen the damp patch and the hole in the roof)

It does get easier with experience though, and much more so if you are regularly doing the same kind of software projects.


In general estimates are risk assessments. With that in mind, I think the way to go about estimates depends on the experience level of the indivual or team. The best estimates are not only a number (or a t-shirt size), they also include a list of possible things that can go wrong (either as an internal dialog or, in the best case, written down as part of the estimation).

There are many methods to get this assessment. These are the ones I have used:

* Basic level: Write down everything that needs to be done and assign a time estimate (in hours, otherwise break down further)

* Intermediate level: Write down everything that needs to be done and assign a range of time in days (from best to worst case scenario)

* Expert level: Use an abstract scale (like the fibonacci sequence, T-shirt sizes, etc)

* "We've been doing this together for 20 years" level: Can it be done in XY time? Yes or No answers only.

In each of these levels the specific time it will take to complete the task becomes less and less specific. The reasons to keep it specific, are a) to learn how to estimate well and b) to keep people accountable. Reasons to keep it unspecific are that a) it's impossible to get a correct number for a task you've never done before, thus b) it's a waste of time to try and make an estimate accurate.

The value of all these estimation techniques is to find out where the most risk lies (usually there where the most unknowns / complexity lies). If you then don't follow up on those risks by checking in with the team, the estimation becomes useless. If you manage these risks well, you should at the very least have consistent estimates. Even if their real-time equivilant is off, it should be off by a consistent amount.

Most important of all though: Estimatation is a learned skill and not inherent to anybody (developers or managers). It takes time and practice to get going accurately.


At this point I just make a quick guess and try not to spend any more time thinking about estimation. In my experience, all time spent estimating is time wasted. If there is some hard date that needs to be met, I have the luxury of ditching features that we don't end up having time for. If you're in a situation without that luxury, you have to everything in your power to keep expectations in line with reality.


I'd first do some research into why your old estimates were wrong - did the teams underestimate the work? Or were they right about the level of effort, but had their time and energy sucked into other things that prevented delivery?

I've ask because I've seen large orgs have accurate estimates, but lay those estimates out incorrectly on the roadmap because the product managers overestimate what percentage of time is actually spent working on the products.


> often we end up delivering 20-30% of what's planned for the year.

That is amazingly bad estimation! You must have some big systemic issues if you can repeat such a failure even twice and still do estimates. Why bother if you're that far off?


I agree. Actually this is just fake estimation, it's really this: being pressured into commiting to doing 3 times as much as you can do.

If the goal was a genuine estimate, the next year you would surely multiply your estimate by 3 and get closer, maybe overestimate that year


I worked for a company a few years back and we had a project to add a feature to our product (a dashboard for small businesses to manage their listings on Yelp, Citysearch, Foursquare, etc). The new feature would let them create a promotion like 10% off, post it to their listing pages, and let customers redeem using a QR code.

We planned out all the epics (create promotion flow, promotion landing page, redeem flow, etc) and sprints. I think it was six 2 week sprints, or about 3 months.

Then the scope creep happened. We agreed on just a "send now" button in the designs, but marketing decided that a scheduling feature was necessary. Somehow we got bogged down building the scheduler and doing timezone calculations (e.g. what if a business located in Pacific time has an owner in Eastern Time who is traveling to Central time, when should a promotion scheduled for 6pm actually get posted?).

In the end we ended up taking twice the estimated time for a feature that was only used by 0.2% of paying customers (it turns out that businesses either already have a coupon system or they don't want one at all).


I still like Fogbugz's Evidence-Based Scheduling, and Agile's fibonaci-based concept of Velocity:

https://writemoretests.com/2012/02/estimating-like-an-adult-...

https://fogbugz.com/Evidence-Based-Scheduling/

https://blog.fogbugz.com/evidence-based-scheduling

https://support.fogbugz.com/hc/en-us/articles/360011258994-E...


I don't do estimates. I put anchor dates months in advance, and track progress with the different teams through weeklies.

Project planning that breaks tasks down into granular dates just begs everyone to disrespect it once dates inevitably start slipping. Don't do that, just keep an eye on the important dates and give your teams the headroom to work.

In your case I'd set strategic goals for the year to align with the business, then plan anchor dates (such as key releases) on a month or two month level for the entire year, then work back dependency and tech roadmap from there.

Also keep some capacity in reserve. Plan your yearly goals conservatively but your anchor dates a bit more aggressively.

Then once the plan is in place, keep track through weeklies or something unobtrusive like that.


Estimating a task and estimating a program of work are completely different things. Task estimation is only ever accurate in aggregate. If you can estimate free of outside influence (ie gaming the system) then you can assume an equal amount of over and underestimation making week by week velocity relatively stable. Outliers happen no matter what. Estimating a program is mostly futile. Not because task estimation is impossible but because project requirements are moving target. That's pretty much the whole point of agile. Ability to adjust to changing priorities comes at the cost of predictability but it's a worthy tradeoff because building the right thing trumps everything else. You can measure your completed backlog against the outstanding backlog to get an idea of progress and forecast when you'll hit the 37th next priority but that isn't necessarily going to the day that you're "done" because priorities shift.


Estimates that are most successful, in my experience, leverage four perspectives: realistic (for people who prefer a quick approximation), optimistic-pessimistic (for people who prefer ranges and risks), and equilibristic (for people who leverage critical path and critical chain). The mnemonic is ROPE.

https://github.com/SixArm/sixarm_project_management_rope_est...

Estimates as work-hours by the person most-likely to do the work tend to work the best in my experience. Estimates as work-hours also are clear and direct for upper management, or across to other stakeholder organizations.

If your estimates are solely within one team or sprint, then story points tend to feel fun and easy. If you can skip estimates all together then that's superb-- it helps to have a skilled team and also a high trust environment.


Did you mean to link here? https://github.com/sixarm/sixarm_project_management_rope_est...


Yes thank you so much for that good catch. Much obliged!


My team landed on a process of breaking projects down into milestones and then tasks and being consistent with buffers for both internal and external parties.

As a side project, I actually built a tool to help with this: "Calculeeto" (http://calculeeto.herokuapp.com/). Besides walking you through the process of breaking down your project and adding buffer, it also has features to assign dependencies and generate a schedule based on number of teammates -- it even adds time for communication overhead: http://calculeeto.herokuapp.com/?debug4

I never launched or finished it but it seemed useful.


Wild assed guess then multiply by two to four depending on how little you trust the people you're giving the estimate too.

Estimates for anything other than the next couple of tasks planned in detail are entirely useless 100% of the time and you never benefit from under estimating.


Using the estimation session to highlight missing / poorly specified requirements, or discover external dependencies can be a worthwhile exercise IMO, the actual numbers are fairly worthless.

For what it's worth, most places I've worked at pretend to use points, but at some point directly translate the points to days anyway.

Also in the last 10 years (which is roughly when I started to encounter agile in the workplace) I've not worked anywhere that didn't have its release schedule set by marketing or product or legal. Yet everywhere paid lip service to developer estimation.

Also, also, I've never encountered an Epic which got over-estimated, which kind of gives the game away doesn't it?


Lots of schools of thoughts. I'm personal very adamant about light-weight process around story-points and sprints. I've found it's the most reliable way to manage expectations external to the team and help the team drive to clarity.

On some teams, we're trending towards "story-count" rather than points. These teams are typically executing extremely well and don't need the (small) overhead of points.

-----

John Cutler has some good thinking on this issue: https://medium.com/hackernoon/work-small-even-if-it-makes-no...


Has anyone tried Planning Poker? https://www.mountaingoatsoftware.com/agile/planning-poker


Good with 3-6 people who are prepared, ie. what are the designs/requests/requirements. Many times PM thinks its a small feature or vice versa when all engineers give a big/small estimate; they get a reality check, same can be said about backend and frontend. And it is good to discuss different PoV between the numbers. I don't think you necessarily need the poker meeting part if you are able to prepare, discuss, estimate with other means; but if you have team members not able to put the time in for whatever reason it can be good to put some scheduled time in for it.


Your having a laugh?


I was not aware of any negative sentiment about planning poker/scrum poker.

I was briefly informed about it during a scrum event and didn't saw it mentioned here.

And it's about estimating project tasks. So relevant to the question.

My guess is that you or the down voters don't know it. Correct me if I'm wrong.


I read this somewhere about how to do estimates and it has stuck with me:

"Double the number and increment the unit."

This is a simple formula to calculate how long something takes to go from idea to production.

So, 3 hours becomes 6 days; 2 weeks is 4 months, etc.

Enjoy!


So 4 months is 8 quarters or 8 years?


20-30%? Yeah thats bad and I know why. You guys think you are producing cars when in fact you are designing cars. Ask yourself the following question: what would you do if you were managing a tier 1 soccer team? Would you treat every player equal? No. You would let each talent play where its good at. Stop thinking your engineers are replaceable. You are not in a factory.

In short, there is someone in your team who knows how to estimate. Find him. Find who is good at what and use their f-ing talent.


Same way I did 20 years ago, I get to play "guess the number I'm thinking of." Only now I play it with a product person instead of my manager.


No estimates has the highest potential for improvement. Estimates are often wrong. In many organizations they are reliably wrong. Without spending time on estimates and wondering how to make them accurate, you can:

* Make risk assessments: Which tasks are most likely to cause a schedule problem or where an implementation approach could fail.

* Spend more time on retrospectives. Retrospectives are more valuable than estimates because the data is accurate.


Take what I think it will take to do in an ideal world and multiply by 3. I usually deliver a tad early because it’s never an ideal world.


The 3 times rule is good, I also apply it quite often, although it's not always an easy sell.


This is not an answer per se, but you might find it interesting :-)

https://erikbern.com/2019/04/15/why-software-projects-take-l...


Funnily enough, I just saw this link pop up: https://blog.pragmaticengineer.com/project-management-at-big...

"How Big Tech Runs Tech Projects and the Curious Absence of Scrum"


TL;DR only estimate the next milestone.

Estimates become less useful the further out they are. To get useful info about how long a project will take requires two large changes; careful definition of the problem and effective scoping of deliverables to validate your solution.

I push teams to understand the problem before attempting any implementations. Without this context people usually make something awesome that isn't useful. That's another thread on how.

The big hack is figuring out what can be delivered to test your assumption quickly. I shoot for about a month of work for this. Give or take.

Up front you get the team to agree, "this milestone should be easy to deliver, assuming we understand the problem and our assumptions are right". Then, if you miss that deliverable you stop work on the project and figure out why you were wrong.

This stop is meant to combat the Sunk Coat Fallacy. Then you can try a new approach, cancel the project, or keep going having only "wasted" a month. These are called Kill Metrics sometimes.

Long term estimates commonly fall to Sunk Cost issues in my experience. This is where a rush hits at the end and you get low quality product.

It takes a shift in how engineering communicates with other orgs to pull this off. You need to account for their needs in the milestones and keep them in the loop as a final delivery date comes into focus. It works to go from second half of the year -> Q4 -> Nov -> date. As long as you refine those with enough lead time.


This is why I hate being a manager


jbay808 had a really interesting comment about six months ago about the relationship they'd found between estimates and actual completion time:

"When we plotted the data, in all cases, the actual time was very accurately fit by a lognormal whose scale parameter was precisely the predicted completion time."

[1] https://news.ycombinator.com/item?id=26366112


2x whatever time I think it’ll take.

Most of the time expectations matter. Only sometimes time to market really matters. At that time nobody asks for estimate


In frameworks like scrum, where estimates are crucial, developers adjust/hack estimation according to their needs.


whatever you say, caveat it with a risks, constraints and assumptions and put an appropriate dissclaimers in with the estimate eg that this is an approxiamate plan and it will be subject to change etc..

The number of times that I've been tried to be held accountable for guesstimates is just not funny


We estimate our Jira tickets in t-shirt sizes:

- XS = +- 1 day of work

- S = +- a few days of work

- M = less than 1 sprint (= 2 weeks)

- L = a few sprints of work

- XL = months of work


I highly recommend the book How to Measure Anything for estimation strategies generally.


From my experience it is always the simple 80/20 rule. The last 20% takes around the same time as the original 80% estimate.

1. Break down "project" in small enough Tasks. Measured in days or weeks and not in months. The scale and margin of error tends to be wrong once you are in the months category.

2. Ask your frontlines ( Engineers, Sales or whoever that is doing the actual work ) to do Estimate for 80% of those task. Not their Managers. You should also know their personalities in their numbers. Some give you numbers that are too conservatives, some are too aggressive. And needs to be adjusted accordingly.

The total Add up Estimate for the project will be the time for you to reach 80% of your Goal. This tends to be +/- 20% accuracy.

The remaining 20% will somehow take the same amount of time for your initial 80%. The reason for that is in tech speak, we are very good at measuring and estimating bandwidth, but absolutely appalling at measuring and understanding context switching and latency. The amount of small things are the remaining 20%.

So if the original estimate of 80% is 10 months, the worst case scenario would be 10 months + 20% = 12 Month and doubling that to 24 months. And if you are the top of the line project manager, you should also expect that 24 months to be within +/- 20% accuracy. i.e You should report your number as 28 months to your line of report to save your ass.

I find this rules to be reasonably good. Ignoring catastrophic failure and other external factors. I mean if your whole team quit mid way there is no way your original estimate could factor those in. Remember, estimate are, just guesses. There is absolutely no way to be certain. I think this rule is simple and straight forward enough to be used across any industry.


Cynefin: obvious, complicated, complex. Also influences the metrics used.


Take a guess, multiply by 2 or 3 according to what happened last time.


Guess how long it ought to take, double it, then double that.


Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

https://en.m.wikipedia.org/wiki/Hofstadter's_law




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: