Let’s face it, estimating software requirements is not easy.

Estimates have to account for a ton of diverse factors, including scope, amount of development required, QA, past team performance, deadlines, complexity, and risk.

For product teams, it’s perhaps the hardest part of their jobs. But why?

 

Common Estimation Pitfalls

• Lack of training on estimation leads to poor estimates
• Not enough backlog grooming meetings with the primary groomers and estimators (Product Manager + Dev Lead + Developers + QA)
• Each product team estimates with a different point scale
• Utilizing absolute time estimates instead of approximate hours
• Not including risk in estimates

 

Bad Estimates = Bad Things

Get estimates right, and your product team is smooth sailing. They can give the product manager new insight into the level of effort for each work item, which makes their prioritization of the backlog much easier.

Get them wrong, and you can negatively impact the product team and miss deadlines… and perhaps even hurt the business with lost customers and revenues.

I’ve seen firsthand that poor planning can lead to product teams working late at night and weekends to hit an impossible deadline. This may lead to a fear of estimating, where they may spend too much time trying to develop the “perfect” estimate for each user story or task to avoid being blamed for wrong estimates.

Ron Jeffries, an Agile Manifesto signatory writes that “estimates are often misused. Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins” (Jeffries, 2003).

That said, let’s look at some ways to make agile estimates as accurate as possible.

 

The Optimal Method for Streamlining Agile Estimates

I’ve found the best way to estimate is to use… wait for it… hours!

Yep. Hours.

Here’s how:

Step 1: Agree on What’s Included in Estimates
For me, I like to account for as many factors in an estimate as you have available, so everything from scope, amount of development required, QA, past team performance, deadlines, complexity, and risk. Sounds like a lot, but it will become second nature as you go through grooming and estimating exercises.

Step 2: Use Approximate Hours
Make sure your team is using approximations of hours, not exact or absolute hours. These are just estimates after all, and they’ll likely change a few times before they’re pulled into a sprint.

Step 3: Agree on the Scale for Each Level (Epics, User Stories, etc.)
Agree on the scale you want to use for all product teams and all requirements. I placed the scale I typically use below, but feel free to modify yours to suit your team’s needs and capabilities.

Step 4: Start Estimating!
Ok, so for epics you’ll want to use t-shirt sizing where your team will need to agree on the appropriate size equivalents. Once you do that, then you do the basic math to get it down to hours.

 

The Benefits and Rationale for Using Hours vs Points

I know, pretty much everyone else says to use points. But here’s why they’re wrong.

Common Unit of Measurement
It provides a common unit of measurement throughout the Agile process across disparate teams.

Simplifies Estimation Training
Provides an easier method for all teams to quickly learn estimation techniques using Fibonacci sequence. This is especially true for new Agile teams and practitioners, points can be a difficult concept to learn. And honestly, do you need more headaches to deal with in the middle of Agile adoption?

Meets Key Objectives
Meets the key objective of more approximate estimates early on (Epics + User Stories) and more specific estimates later (Tasks + Sub-Tasks).

Provides Actionable Data
One of the biggest benefits over using points is that it provides clear and actionable hourly estimates at all phases of agile, from epics all the way down through tasks and sub-tasks. So it really helps to more accurately plan resources, timelines, and budgets.

 

Accounting for Risk

Typical naysayers will ask – in their typical valley-girl accent – “so how do you, like, account for risk?”

I personally believe that Agile inherently includes risk in the estimates by breaking big chunks of work down into smaller incremental requirements, as well as working in short iterations and failing fast.

With that said, there’s always small amounts of uncertainty in all user stories, especially if something hasn’t been done before. But if there are still big unknowns about a user story, then you shouldn’t estimate it. Simple as that.

Or you can always create another user story (or series of user stories) to create a small proof of concept (POC) to test assumptions without spending larger amounts of time building out the full feature. Simple as that too.

 

Hours in Action

 

We used hours to estimate user stories at Marriott on the E-Commerce team, which greatly simplified the estimating process and provide actionable data to support the PMO.

 

I also standardized it at PwC and utilized it for all of our Agile engagements with clients.

 

 

Conclusion

Going back to my original post on The Agile Movement Drives Innovation, where I outlined the key aspects of moving to an Agile methodology:

With that note in mind, you should be creating an Agile environment where there’s a level of safety for teams to fail and learn over and over again. Estimates will improve as the team learns more about the product and through collaboration in backlog grooming exercises. These activities will build the team’s confidence and make predictability easier and better over time.

The results of using hours will provide more accurate data to use in planning, which will enhance planning to better convey useful information to stakeholders and management so that they can make reliable decisions.

And lastly… I’m right. And the naysayers are wrong.

It’s like, as simple as that. Totally.