How To Estimate Effort Like A Product Manager
Learn how to anticipate & plan the amount of work needed to complete an initiative before the end of a quarter.
When software development teams are planning what to build, they are not just planning what kind of features need to be developed to solve the customers problem. They are also thinking about the trade-off between time and effort, that being the effort it takes to complete developing a compelling solution against the time it might take in order to fully complete this.
There must be a balance struck between these two elements, as the more complete a feature needs to be to be considered ‘done’, the more time it will take on the development and validation side to ensure that the feature is well-polished enough to be considered ready for use by the user. As a product manager, it is your responsibility to not only ensure that the feature satisfies the definition of ‘done’, but that the effort required to do so does not start to eat up the opportunity cost of what the team could be doing otherwise with their time.
In order to ensure that both time and effort are balanced when delivering an initiative, a product manager should strive to estimate this effort beforehand. Granted, estimating effort in software delivery is fraught with difficulty, uncertainties and runs into the plain old phrase that, “Software delivery doesn’t operate like that!”. However, what I’m suggesting here is not an adherence to the minute by minute passage of the clock when it comes to the completion of an initiative.
Rather, it is about being able to:
Break down the initiative into the epic and associated user stories
The first step to estimating effort is to first understand the work that needs to be done. This is done by breaking down a big initiative into the number of epics required to complete it, as well as the associated user stories under each of the epics that need to be completed to consider the epic as ‘done’:
By breaking an initiative down into it’s component epics and user stories, this helps the team know:
- What the exact shippable components of work look like;
- What are number of stories and/or tasks that need to be done to have a complete shippable component of work; and
- Allows estimation of effort for the user stories and/or tasks on a sprint by sprint basis
Please feel free to read my article here and here if you want to learn more about how to write an epic and user story like a product manager respectively.
Understand, on a sprint by sprint basis, the amount of effort it will take to complete a certain set of stories
Once the initiative has been broken down into it’s component epics and user stories, the next step is to then plan out how much effort is required by the team in order to complete each component of work. This typically involves just estimating the effort required to complete the user stories associated with the different epics.
As a product manager, it is not your sole responsibility to be estimating effort. What’s more likely to happen is that you, as the product manager, alongside the engineering manager and the product designer, will come together in what’s known as a ‘product trio’ in order to discuss the breakdown of work and the amount of effort required for each.
You can use any measure to estimate this effort. For myself, I use the Fibonacci method. This is a a series of exponentially increasing numbers used to estimate the effort required to complete a task or implement a user story. In the Fibonacci sequence, each number is the sum of the preceding two numbers:
0, 1, 2, 3, 5, 8, 13, 21…
Below is a quick example from one of my previous initiatives where the effort was estimated for different types of work that needed to be done:
Planning the appropriate number of stories to be completed per sprint to achieve the optimum velocity
Once each of the user stories have been pointed and effort estimated, it is time to put them into sprints. As mentioned in my previous article, the goal of sprint planning is to find agreement with your whole squad on the work that needs to be prioritised and worked on in the upcoming sprint. This is usually done in conjunction with backlog grooming; the purpose of the latter being to organise and prioritise tickets with a small leadership group within your squad on what needs to be discussed during the upcoming sprint planning session.
As the product manager, it is your main responsibility to find agreement within your squad on the work that needs to be prioritised in the upcoming sprint. Despite the ‘manager’ in the title, a product manager is the manager of no one, and the only way for work to get done is to subtly influence the opinion of the squad to find total agreement on the work that needs to get done in the first place.
Each sprint should have enough ‘pointed’ stories that, by the end of planning, you and the team are confident that they can complete all of the stories by the end of the sprint. Of course, this is not always going to be the case, as estimations are always crude and rudimentary, even in the best of scenarios. There may be cases where all the stories are completed even before the end of sprint, or where some of the stories remain uncompleted even by the end of the sprint.
Using the ‘optimum velocity’ to consider how many stories can be completed in the backlog before EOQ
This is where it is good to adjust the number of pointed stories on a sprint by sprint basis so that the team can achieve the optimum level of velocity. The term ‘velocity’ here means that your team are consistently maximising the amount of effort and time needed per user story throughout the sprint that they, theoretically, finish every sprint with no user stories left by the end of it. This doesn’t mean finishing the sprint early — this means that the last user story is completed on the last day of the sprint.
This efficiency of effort and time is known as velocity and is key in helping a product manager plot out:
- How much work can be completed in the quarter; and
- What would the end feature look like by the end of the quarter, should some of the user stories remain un-finished by the end of it.
This helps a product manager not only estimate the amount of effort required to complete an initiative, but to have a future glance at what the feature might end up looking like so that he has the freedom to work with sales and marketing on selling & marketing the end feature respectively.
Conclusion
Follow the above tips and you’ll be estimating effort like a product manager in no time. Please use the following link if you like to have your very own copy of my epic and user story Notion template via Gumroad!