In my experience, software development projects are notoriously difficult to estimate. That's one of the reasons, I think, we have invented a slew of processes to try and reign in out of control projects. Agile processes like SCRUM and SAFe were invented to break down software projects into manageable chunks and make them predictable. Still, predictability in software development is a complex beast to tame.
I've developed for and managed many waterfall software development projects over the past 30 years. The typical development cycle for major upgrades to software suites (large solutions) always seems to be about eighteen months. While we didn't often miss the mark when it comes to requirements, eighteen months is too long for marketing to wait on product. A year and a half is eighteen months of lost opportunity.
Of course, there are products that justifiably take years to build, due to their complexity. Predictability is still a very important factor when trying to sync up your marketing with your MVP. Coordinating an effective product launch requires notifying users with increasingly detailed teasers and maybe even presales. At the same time you're working on marketing, you're trying to manage funding, and development. Three things you don't want when launching new products:
- Wasting money on marketing too early in the process.
- People losing interest because your product is late.
- Running out of funding before your MVP is complete.
For these reasons, I favor Agile processes over waterfall even when you release on a "waterfall" timeline; however, using Agile processes doesn't magically fix your predictability. That's because great developers suck at estimating time. Good developers are great at estimating complexity, though. So, when managing a project, I push the developers to estimate their work based on how hard it will be.
- Is the work easy?
- Is the work moderately complicated?
- Is the work very difficult?
- Are you throwing up?
By breaking work into two week sprints, executing a few sprints, and ensuring sprints end in completed work, you can calculate how long it takes to complete tasks with varying complexities. That, my friends, leads to predictability...at least...it leads to more accurate predictions when compared to waterfall.
Your developers predict complexity and you translate complexity into timelines.
Some things to note:
- Don't let your senior developers bias your complexity estimates. My preferred method is to use some form of planning poker.
- Do whatever you can to keep developers focused on complexity and avoid asking them for time estimates, because they will lie to you. (Not on purpose. Good developers suffer from time-blindness.)
- Bugs are almost purely research. If you absolutely must ask a developer for a time estimate, don't ask them to estimate bugfixes. It is impossible to know how long it will take to find a solution to a research problem. What is predictable is how long it will take to fix it once the research is over.
After your team has estimated complexity, and you have truly completed some tasks of varying difficulty, you can calculate the team's "velocity." You can then use velocity to predict timelines and sychronize with your marketing.