It can seem daunting to estimate the effort involved in a large software project. And it’s easy to start thinking: “Because estimates are always wrong, they aren’t that valuable.”
But there are many benefits of estimation. If you get in the habit of estimating regularly, you can turn a daunting, nonproductive exercise into one of your most powerful tools.
I’m going to give you a few concrete checkpoints and exercises that will turn estimation into a regular practice for your team. I’ll look at three excellent times to estimate, explain why each is valuable for estimation (or re-estimation), and give some methods you can use to create estimates.
1. Before a Project Starts
This is probably the most obvious time to estimate your software project. What are the benefits of estimating a project before it starts?
- It helps you define what the product you’re building is.
- It forces you to create an initial plan for how the work can be organized, built, and deployed.
- It can help you sell your project internally to stakeholders. If your plan includes a rough timeline, it generates more confidence.
- The timeline that comes from your estimation helps you understand the development effort and capacity needed to complete your project in a reasonable time. You’ll be able to staff your project for success.
Atomic uses several different methods to estimate the size of a project, including comparisons to previous similar projects and bottom-up ranged estimates. We usually combine several methods to get a better perspective.
2. Before Each Milestone Begins
Estimation is always done at a particular point in time. You apply everything you know right now to paint the clearest picture you can. If you never revisit your original estimate, you are going to miss your targets.
So before you begin work on a milestone, you should re-estimate the effort required to complete it. When you’re about a month out from starting the milestone, use everything you’ve learned since the beginning of the project to make a better estimate.
You can also leverage your estimation to uncover which upcoming areas of work have the most risks or unknowns. And you can identify low-return, high-effort areas that can be cut before high-fidelity wireframes are created.
One of my favorite estimation exercises at this point is the bottom-up ranged estimation exercise mentioned above. Even if you’ve already estimated using the same technique, you’ll now have a much better understanding of what’s included in the upcoming milestone. You’ll also be equipped with knowledge about previous milestones and how they compared to their original estimates.
This will help you get a clearer picture of your project, though not as clear as you can get. For that, you should estimate one more time after settling on UI/UX.
3. After Designs Are Approved
This is core to the Agile software process. Using your approved designs and business requirements, estimate the relative complexity of each user story.
This is another fantastic place to look critically for low-return, high-effort areas that can be cut. For example, it’s common that a technical hurdle is overlooked during planning but uncovered when you break down the approved designs.
It’s also your best chance at hitting a more precise target, as you can use historical velocity to project an end date.
Conclusion
Estimation is often underutilized because its complete value isn’t understood and because it forces people to deal with ambiguity and uncertainty. However, bringing estimation into each part of your project can help you build confidence that you’re on track — or help you identify much earlier if you need to adjust your course.
I hope these practices can help you succeed with your next project.