You’ve been listening to customer feedback and identified an area of huge potential value for your product. You’ve facilitated a Product Design Sprint to build a prototype for a working solution, and validated that solution with user tests and customer research. It’s time to build, so you turn to your design and development teams and ask: “How long will this take?”
Accurately estimating the time it takes to build a feature is a common pain point for product teams. Some describe software estimation as an “art”, slowly honed by years of experience managing products and people and maneuvering around technical and procedural roadblocks. Others think of it as the “science” of breaking down features into the smallest possible tasks, then adding up the time each mini-task should take to complete. Pages of web search results offer formulas to answer the question, “How should I make an estimate?”.
In our experience, answering that question often starts with instead asking: “Should I make an estimate?”
Is time estimation the right tool for your team?
Every tool we use has a specific purpose and is better suited to some tasks than to others. Just like you wouldn’t reach for a hammer to tighten a leaky faucet, time estimation isn’t always the right tool to reach your goals. The introduction of any process is inherently a set of trade-offs, and weighing those trade-offs is often the best way to decide whether it merits inclusion in your team’s workflow.
One consequence of time estimates is that they create a de-facto deadline: If we estimate that a feature will take two weeks to build, we set the expectation that stakeholders will have that feature in their hands in two weeks. I call these kinds of deadlines “lurking deadlines”, because they are not explicit and they are often arbitrary; there are no real consequences for taking an extra week to get it right, and many stakeholders are happy wait a week for a stronger product.
This isn’t to say that time estimations will always be a drain on your team. The problem arises when estimating becomes a default part of the process for every new feature, regardless of what (if any) value it adds. We’ve all felt the pain of working under a time crunch because development took longer than our initial estimate, and it can be easy to fall into the trap of working unsustainably or incurring extra technical debt to meet it.
“Why do you want to know?”
I asked my colleague for his first reaction to the “How long will this take?” question. He looked at me, narrowed his eyes, and asked back, “Why do you want to know?”. This response made in semi-jest makes a great point. There should be a reason why we have to put a time frame on a particular product priority.
Perhaps the most obvious case for a time estimate is an actual hard deadline that is outside of your control. Is there an upcoming conference for your industry where you plan to promote your new feature? Is there some pending press coverage you need to be ahead of? Are you running out of money and trying to add value rapidly?
Deadlines can be unavoidable, and they’re not necessarily bad. Is there a deadline that is out of our control? If not, what do we gain by creating one? It’s useful to be strategic about when the time pressure is worth it.
Create priorities, not deadlines
It’s easy to mistake setting a deadline for creating urgency, and meeting a deadline for success. But the process of building a great product is more than a streak of met deadlines. Building a product requires constantly juggling priorities that will add real value for customers. Absent a hard deadline, the ideal answer to “How long will this take to build?” is often “as long as it takes to get right”. But how do you maintain urgency without the constraint of a time frame?
This is where your iteration cycle can be great. Are the items in your task management system prioritized appropriately? Is your team achieving a reasonable balance of velocity and quality? Is everyone sharing their concerns, successes, and blockers at daily standups and weekly retros?
If the answers to these questions are “yes”, you’re likely making quality, sustainable progress towards your goals. The daily and weekly check-ins should give you a gauge of when a project will wrap up. You’ll also have the added benefit of basing your predictions on real-time progress, rather than an arbitrary deadline that you set when you had the information.
When you must
So you have a deadline. And you’ve decided to try estimate the development time of a new feature to get a better idea of what meeting that deadline would look like. How might you make that estimate as realistic as possible?
Identify your MVP
What is the smallest change you can ship to reasonably meet your goal? Can you prioritize the work needed to achieve that MVP and add in bonus features later? Keeping the scope of the project tight ensures that you meet your goal and then iterate, rather than trying to tackle everything and once and ending up with nothing to show.
Talk to the right people
It’s vital that the people tasked with delivering on a schedule buy into that schedule. Developers and designers will feel the pain of having an unrealistic deadline imposed upon them. Sales and product team members have valuable insight into the most acute customer needs, and should also be present and available to support the process. The combination of these perspectives can help focus scope and set realistic goals.
Be realistic about your resources
Deciding what resources you have to dedicate to a given priority is about more than how many developers or designers you can staff it with. More people doesn’t necessarily mean more velocity.
Be realistic about how many people are available to work on it, how familiar they are with the product area, and what other responsibilities they currently have. Are they also onboarding a new developer, or on call for production incidents this week? Make sure you have an accurate accounting of what other priorities are competing with feature development.
Plan for setbacks
People get sick. High-priority production incidents happen. Assume that one or more of these things will happen during your feature push.
Account for all of the time spent on the project
Not all time spent working on a project is heads-down development time. It might also include gathering requirements, communicating with other teams, addressing technical debt, and adapting for changing product needs. Be sure to account for this time in your estimate.
Make estimation iterative
It can be tempting to think you need a formal estimation process to get it right. Instead of building process, try incorporating estimation into your existing process. Rather than calling a meeting at the beginning of your project planning to settle on a date, try starting off with an estimate and a confidence level: “I am 70% confident that we can finish this by December 12th”.
Revisit your estimate at every retro. Hopefully your confidence level will increase as you get closer to the deadline. If you encounter blockers that lower your confidence or push back the date, you can react earlier by moving the deadline or reducing scope.
Estimate when it’s helpful, don’t when it’s not
Estimation, and the implicit deadlines that come from it, absolutely have a
place in software development. They can help you make better decisions faster
instead of dwelling on minutiae. They can help you plan to meet a deadline that
is out of your control. They can even be useful tools for cost-benefit analyses:
If a feature will take x number of developers y number of hours to build,
will it generate at least $z?
But they can also be a source of unnecessary time pressure that can lead to shortcuts and burnout. We recommend adapting your estimates to your iteration cycle, rather than the other way around.
Questions about how we handle estimations? Reach out to us on Twitter! We’d love to hear from you.