[HN Gopher] Ask HN: How do you do estimates in 2021?
___________________________________________________________________
Ask HN: How do you do estimates in 2021?
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.
Author : buttonsmasher
Score : 83 points
Date : 2021-09-26 17:43 UTC (5 hours ago)
| Calamitous wrote:
| 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.
| jeremyis wrote:
| 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.
| byoung2 wrote:
| 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).
| erdo wrote:
| 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?
| thrower123 wrote:
| Guess how long it ought to take, double it, then double that.
| erdo wrote:
| Take a guess, multiply by 2 or 3 according to what happened last
| time.
| [deleted]
| Dragony wrote:
| 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.
| quadcore wrote:
| 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.
| diiq wrote:
| 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/
| codingdave wrote:
| 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.
| boxed wrote:
| > 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?
| erdo wrote:
| 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
| lax4ever wrote:
| 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.
| erdo wrote:
| 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.
| ClassAndBurn wrote:
| 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.
| pjerem wrote:
| 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.
| candiddevmike wrote:
| 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.
| byoung2 wrote:
| 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.
| NicoJuicy wrote:
| Has anyone tried Planning Poker?
| https://www.mountaingoatsoftware.com/agile/planning-poker
| Redsquare wrote:
| Your having a laugh?
| tobyjsullivan wrote:
| I highly recommend the book How to Measure Anything for
| estimation strategies generally.
| 123pie123 wrote:
| 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
| SkyPuncher wrote:
| 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...
| SkyMarshal wrote:
| 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...
| nzmsv wrote:
| 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.
| geoduck14 wrote:
| I think I need to talk to my therapist after reading this
| [deleted]
| aasasd wrote:
| 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.
| 0_____0 wrote:
| I remember one of Akin's Laws of Spacecraft Design being
| something like: take your original estimates, multiply the
| time by p and shift the decimal on cost one place to the
| right.
| snypher wrote:
| 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.
| aasasd wrote:
| Also related: always multiply your estimates by pi
| https://twitter.com/henebb/status/744195986017366016
| dharmab wrote:
| I personally multiply by 3 for any process which isn't almost
| entirely automation.
| sgtnoodle wrote:
| 3x fits pretty much every engineering project I've worked
| on.
| catlifeonmars wrote:
| 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.
| edoceo wrote:
| Where is the joke? This sound like SOP.
| [deleted]
| kadonoishi wrote:
| 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
| dang wrote:
| 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)
| flyinglizard wrote:
| 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.
| aluminussoma wrote:
| 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.
| serial_dev wrote:
| Can you tell more? I would be interested how you can get
| management to let go of regular estimations, and how you still
| delivered.
| void_mint wrote:
| > I would be interested how you can get management to let go
| of regular estimations,
|
| They have to convince themselves.
| ThalesX wrote:
| If they pay a lot of money per hour, they basically
| convince themselves of whatever it is they're paying for.
| pjerem wrote:
| 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.
| jph wrote:
| 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.
| Narretz wrote:
| Did you mean to link here?
| https://github.com/sixarm/sixarm_project_management_rope_est...
| jph wrote:
| Yes thank you so much for that good catch. Much obliged!
| hizxy wrote:
| This is why I hate being a manager
| tootie wrote:
| 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.
| issa wrote:
| 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.
| anschwa wrote:
| 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!
| WesleyJohnson wrote:
| So 4 months is 8 quarters or 8 years?
| 28304283409234 wrote:
| Cynefin: obvious, complicated, complex. Also influences the
| metrics used.
| S_A_P wrote:
| 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.
| mk89 wrote:
| The 3 times rule is good, I also apply it quite often, although
| it's not always an easy sell.
| void_mint wrote:
| 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.
| erdo wrote:
| > 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
| gregmac wrote:
| 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?
| eikenberry wrote:
| 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.
| void_mint wrote:
| > 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.
| Leherenn wrote:
| > 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.
| void_mint wrote:
| > 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.
| KronisLV wrote:
| > 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.
| void_mint wrote:
| > 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.
| KronisLV wrote:
| > 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.
| void_mint wrote:
| > 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.
| KronisLV wrote:
| > 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.
| erdo wrote:
| 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.
| KronisLV wrote:
| 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.
| gumby wrote:
| > 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!)
| void_mint wrote:
| 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.
| gumby wrote:
| > 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.
| ratherbefuddled wrote:
| 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.
| yinzer-solomon wrote:
| 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.
| vansande wrote:
| 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
| PaulHoule wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-26 23:01 UTC)