In my experience, this topic is right up there with naming things, and cache invalidation. We’re all terrible at it, and so many things have been tried over the years to make this necessary activity easier, more accurate, and less painful. SWAGs, ROMs, T-Shirt Sizes, Story Points… these are all attempts to abstract the estimation process into something that works, and from the experiences I’ve had with each, they all fall short of the mark.
There are a few factors here, I think. Most notably, Trust (or lack thereof,) that their estimates will be treated as Estimates. In close second place to Trust is a lack of enough information to give accurate opinions. Without an understanding of the REAL work to be done, we have very little chance of giving a realistic estimate with confidence.
Managers:
If your developers say they need more information about a body of work, please listen to them. If their estimates seem a little oversized, find out why they think they’ll need that much time. Listen to and consider those concerns.
Developers:
Please don’t tell the managers what you think they want to hear. Give your honest assessment of how much time something will take you. Be prepared to support your estimate with concrete reasons. If there’s not enough information to assess, ask for that missing context and follow up after you’ve a clearer picture of what’s needed.
Both:
Estimates MUST BE treated as estimates. The accuracy and confidence of an estimate is directly proportional to the accuracy and completeness of the background information.
Throughout my career as a developer, I’ve given SWAGs and ROMs in good faith, only to have those end up as a line on a Gannt Chart far too many times. I learned to pad those, which in retrospect, was an equally bad move. Parkinson’s Law states that the work will grow to fill its allotted time on the schedule. This usually manifests as “gold plating” and Gold Plating is where bugs lay their eggs. Let’s agree not to build detailed project plans from off-the-cuff, in-the-moment estimates, please?
Story Points are not units of Time. Unfortunately, almost everyone subconsciously turns them into units of time. Bad Things happen after that. Understanding the complexity of a requested body of work is useful, but realistically, it’s only the first step.
Planning a Software Development effort is a complicated problem, with a lot of different people in the mix with different needs. Based on the context of the development effort, we might take different approaches to the planning and forecasting problem.
We can start by agreeing amongst ourselves (the development community and the people that manage us,) on a few things:
If you, as a manager, ask for a Wild-Guess to gauge level of effort, please treat that answer as a Wild-Guess. Don’t build a project plan on Wild Guesses.
As a manager, you should understand the scope and intent for the work being discussed, before asking for estimates. Include that scope and intent with your query. If you ask for a Proof-of-Concept or a demo/prototype, don’t let anybody pressure your team into shipping it. If you’re asking for a service or module that will be deployed to production, understand that the estimate may be much higher than just writing the code.
If you, as a developer, are giving an estimate, don’t pad it to give yourself wiggle-room. Also, don’t underestimate to make the manager happy. Give your level of confidence in that estimate, alongside the number.
As a manager, when you get an estimate that doesn’t feel realistic, dig in. Get an understanding of why that estimate is higher or lower than you think it should be.
Similarly, if the estimate arrives with a low level of confidence, have a conversation to cut the unknowns, then reassess the estimates together.
As a developer, be honest about your capabilities when estimating. If something feels like it’s beyond your skillset, say so. It’s the manager’s job to either help you get to the point where you CAN execute or assign that piece of work to a different person. Be detailed in your concerns about the scope of the work you’re estimating. It’s possible those concerns have been accounted for already, or that they weren’t considered when your manager asked about them.
We’re all only human, and we’ve all got our own talents, skills, strengths, and weaknesses. Good developers care about producing the best quality products that they can. Good managers care about getting the work done as efficiently as possible, while developing their teams into the best developers they can be.