In Parts 1 and 2, I suggested a systematic way to tackle rough software project sizing for budgeting and strategic business planning. You may not agree with my approach. It’s just a suggestion, a straw-man for straw-man estimating. The point is that software projects are sizable even before they’re fully defined, as long as we qualify our estimates.
Identify the Risks
“The devil is in the details,” as they say. Innocent-looking requirements can blow up into novel and complex problems with intricate solutions. Some typical features that befuddle engineering teams include data synchronization, scheduling algorithms, workflows, and integrations with external devices and services. When you deliver a high level project estimate, you absolutely must call out these schedule breakers. Tease apart what’s known from what’s unknown.
For a work in progress, calibration is easy. You should have many epics to compare against. However, I’d still recommend strongly that you represent your estimates in T-shirt sizes, with stated comparisons to these other features, rather than representing your estimates with inappropriate precision. Remember, when you estimate in person-hours, the implied precision is also to the nearest hour, even if you say +/- 30%. If you state your estimate in person-months, the implied precision is much lower. Like it or not, to most recipients of numerical information precision implies accuracy.
For a green field project, you’ll want to compare complexity to previous initiatives. After three or four iterations you’ll find that you have a pretty clear understanding of how your own scoring system relates to actual effort. If you have the time and patience for it, it wouldn’t hurt to calibrate by retroactively scoring a completed project.
From Complexity to Cost
The final step is to translate complexity into useful, if imperfect costs. It’s worth stating that cost is not synonymous with schedule. Cost is total effort. A timeline is what you get when you match resources with expected effort and dependencies to predict dates.
Time to Complete != Capacity/Estimate
Timelines require planning, not just estimates. However, I do use a rule of thumb to expand total effort into approximate calendar duration. For me, it means Capacity/Estimate + 30%, which is usually (though not always) sufficient to allow for dependencies, holidays, vacations, and unplanned absences.
To Pad or Not to Pad
Be careful about mentioning padding. By which I mean, don’t. If you tell an executive that an initiative will require three months, but that you padded it to four, she’ll hear, “we think it could be done in three months, but worst case is four.” Better to say, “Based on what we know today, it looks like roughly four months of work for 3 software engineers and one test engineer.” If you can get away with it try, “about a third of a year,” or “within two calendar quarters.” Don’t accidentally make promises you can’t keep.
As your team or product stabilizes, complexity scoring will calibrate your business planning estimates. Over time your scoring system may become unnecessary. Most engineers can rapidly assess the complexity implied by a straw man data model or interaction model. The real reason for grinding through scoring exercises is to train yourselves as a team to make better, educated guesses with decreasing effort. As long as you’re vigilant and keep your eyes open for land mines hidden in the implied requirements, you’ll rapidly tune this skill. Be patient. I’ve observed that cohorts are better and faster than individuals at breaking bad habits and developing good habits and skills.
As I said at the end of Part 1, one of the benefits of this top down approach to sizing is that it’s not throwaway work. The insights you glean will lead directly into the detailed analysis required as you populate your Product and Sprint backlogs. Whether you invest a few hours or a few days, you’re sure to end up with a useful technical roadmap, along with a list of clarifying questions for your Product Owner(s).