The Art of Estimations for Product Owners

The Art of Estimations for Product Owners is a tricky one and often most of the time it's is a dicey topic for engineers. When estimation is used badly, developers are forced to give the time (often in hours) against tasks that they haven't had a chance to look into or decouple, and then they are blamed when they don't follow those estimates or hit them for not working hard enough or for being inaccurate.

Estimation is a necessary evil and there are several different ways people use estimations or approach them;

What are the different types of estimating methods?

- Story point estimates

- Actuals

- Coarse estimates

- Planning poker

- Burn up

- Burndown

- 3 point estimates

So, let's look at estimation as a process, we want to maximize RAV, Real value-added time and we want to minimize the BVA, Business Value time, but you certainly want to limit the amount of time of estimates and following up on estimates. The process of estimation is helping us make decisions, prioritize tasks and help keep our overheads in check.

There's a big community that says, that estimates are bad and to avoid them and there are different ways to approaching estimates, like using short circles, looking at the historic and actuals.

When you're looking at batching tasks and prioritizing, you need to know how much stuff you want to get done in integration and the sense of complexity, capacity so that people can pick them up and self-organize.

One of the primary ways we can estimate our backlog is using story points, the idea behind story points can be applied to your stories and your tasks and also, story points are not relative to hours, but relative to the measurement an individual sizes to the work, the scale they implement them is their own as teams get better and developers won't over-prescribe.

High-functioning teams with experience, are often comfortable with estimates, especially those that work more or less in Scrum, there have been instances in the past where I have worked with talented engineers that are not part of teams and work within Kanban that don't provide estimates but mainly provide the 'I'll get it done by today and sure enough they do, it really depends on your team structure, the role of the person and the method you are adapting to. If management wants you to estimate your resources and resources are time, money, people in order to get something done, there might just not be any escape but to do the estimate but do it with well.

doing estimates well

Doing it well means that you have collected input from your team and made an assessment to ensure there are no impediments to delivering working software, if your team is doing integration for something new and they have had a history of actuals where they went over 3x, buffer it in. It's better for a product owner to assess the risks of performance and complexity along with the task estimates process.

negotiate using waterfall techniques to get your point across

Sometimes, when I get into more traditional waterfall type of companies that uses Agile practices in development but still maintain a heavy linear workflow around other departments and certain projects, I like using the method of project schedule variance, similar to burn down, yet measures packages of particular artifacts and I would couple in the artifact as a project or an Epic.

This helps me maintain integrity in reporting on deliverables and also on cost, it's not typical, but when I've used it, I have found that my clients build trust, understand that I am also thinking about the cost impacts, and help them through their MVPs and plan around what they can afford to ensure timely releases to the market are met. In bigger organizations, that require referring up the chain for budget approvals, this helps me plan historic foundations on securing resources I need to make the initiative happen.

Calculating Project Schedule Variance helps me answer some often really uncomfortable yet important questions, but they don't need to be uncomfortable as a Product owner, don't be afraid to negotiate, and for some of us that started their career in a waterfall, it's ok to use this to negotiate and win influence.

Project Schedule Value (PSV)

Actual completion value (ACT)

Scheduled completion value (SCT)

PSV = SCT - ACT

This indicator is important because it lets me answer the following questions;

1. Is the project (epic) on schedule

2. Is the project (epic) on budget

3. Is the project (epic) delivering the specified outcomes?

Most companies and initiatives I've been in have delivered in projects and if we can set up a delivery cycle where things can come out all the time and early on we have a picture of how fast things are being delivered, the measurement would be for me sort of looking back, Bill Wake also shares the same principle there's a great course that summarises the art of estimations in a digestible format you could take with Bill wake's Estimates & Prioritising - Managing an Agile Team with the University of Darden, where he explains the way he looks back as a measurement to then perform estimates for future and present tasks.