So, you have been listening to customer feedback and identified an area of significant potential value for your product. We have facilitated a product design sprint to build a prototype for a working solution to your proposed problem. We have validated that solution with customer research and user tests. You have reached the stage of asking our design and development team, “How long will this take?”.

Estimating the time accurately that it will take to build a feature is a common pain point for product teams. When people refer to software estimation, you may come across the terms “an art-form” which is slowly homed in by experience of managing products and team members dancing around technical roadblocks. Software estimation is sometime also referred to as a “science” of breaking down features into the bite-sized tasks and adding up the time each mini-task should take to reach completion. If you typed into your search engine now, “How should I make an estimate?”, you would get an infinite number of web pages trying to answer the questions. At Launchbase, our experience in answering that question often starts with instead asking, “Should I make an estimate?”

The Time Estimate Approach: Is it Right for You?

Every tool that we use at Launchbase has a specific purpose and is better suited to some tasks than others. Just like would not reach for a screwdriver to hammer in a nail, time estimation is not always the right tool to reach your product’s goals. The introduction of any process is inherently a set of trade-offs and weighing out these trade-offs is the best way to decide whether it should be included in our team’s workflow.

A consequence of using time estimates is that it creates a de-facto deadline. If our team estimates that a feature will take two weeks to build, we set an expectation for the stakeholders that a feature will be in their hands in two weeks. By putting in these lurking deadlines, there are no real consequences for taking an extra week to get it right since many stakeholders are happy to wait a week for a stronger product overall. We are not saying that time estimations will be a drain on your team. Problems arise when estimating becomes a default part of the process in every new feature, regardless of its value. We all know what it is like to work under intense time constraints because development took longer than our initial estimate, and it can be easy to fall into the trap of working unsustainably or increasing your technical debt.

Why Are You Asking the Question?

You can argue that the most obvious case for a time estimate is an actual hard deadline that is beyond your control. Is there an upcoming event in your industry where you plan to promote your new feature? Are you running low on funding and trying to add value rapidly?

Deadlines are unavoidable and they are not necessarily a bad thing. Is there a deadline that is out of your control? If it isn’t, what will you gain by creating a deadline? It is useful to be strategic about when the time pressure is worth it.

Creating Priorities, Not Deadlines

There is a thin line between setting a deadline for creating a sense of urgency, and meeting a deadline for a success. But the process of building a great product is more than a circuit of met deadlines. Building a product requires constantly juggling priorities that will add real value for customers.  When you remove a hard deadline, the ideal answer to “How long will this feature take to build?” is “as long as it takes to get it right”. But how can you maintain urgency without the constraint of a time frame?

This is where iteration cycles come in handy. Are the items in our task management system prioritised correctly? Is our team achieving a reasonable balance of quality and velocity? Are we sharing our successors and blockers? Answering yes to these questions means we are moving towards our 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.

At Launchbase, we understand that when it comes to elements of your product build that cannot be controlled, from funding to time constraints, our team are experienced in facilitating the scope of your product if there are money and time constraints. Adaptability and agility is important to keep in mind when it comes to your product scope and managing expectations of the product build needs to be matched with the constraints that we have to work with. Keep in mind that it is about the journey and not the destination of your product as we create fluid products that thrive in various stages of your business.

When Deadlines are Unavoidable

So, we have established a deadline and we have decided to try and estimate development of a new feature to get a better idea of what meeting that deadline would look like. How might we make that realistic as possible in developing your product?

• Identifying the MVP

What is the smallest change we can ship to meet our goals reasonably? Can we prioritise the work needed to achieve that MVP and add in bonus features later? Keeping the scope of your project tight ensures that we can meet our goals and then iterate, rather than trying to tackle everything at once with nothing to show at the end. We take a deeper dive into prioritising your MVP on our website

• Update the Right People

It’s vital that our team that have been tasked with delivering on a schedule buy into this schedule. Our developers and designers will feel the pain of having an unrealistic deadline imposed on them. Our product team members have valuable insights into the most acute customer needs so they are always available to support this process. The combination of these perspectives help focus scope and set realistic goals for your product.

• Planning for Setbacks

People get sick. Production incidents can happen. We need to assume that one or more off these things will happen during your feature push.

• Account for Behind the Curtain Tasks

Not all time spent working on your product is heads-down development time. It may also include gathering requirements, communication with other teams, addressing technical debt, and adapting for changing product needs so make sure to keep this in mind when receiving your time estimate for your product.

• Making Your Product Estimation Iterative

It can be tempting to think you need a formal estimation process to get your product right. At Launchbase, we like to keep the building process agile and we try incorporating estimation into your existing process. Rather than calling a meeting at the beginning of your project planning to settle on a date, we try starting off with an estimate and a confidence level ie. “We are 80% confident that we can finish this by the 14^th of December.” At every stage, we will revisit the estimate and if we encounter blockers that push the date, we can react earlier by moving the deadline or reducing scope.

Product build estimations and the deadlines that come with this has its place in software development. They can help you make quicker decisions instead of dwelling on the smallest issues. They can help our team meet deadlines that are out of our control. We also use these tools for cost-benefit analysis like: 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 burnout and shortcuts. At Launchbase, we strive to adapting our estimates to your iteration cycle, rather than the other way around in developing a strong and seamless product.

Do you have any questions on how we handle estimations at Launchbase?

Send us a message or visit us on Twitter and we’ll answer your question in no-time.