Feature Estimation: Using Ideal Weeks

Recently, a client asked me what an ideal feature-estimation-week would look like. It was a fairly straightforward question, but I knew she was setting a trap.  We had been training on and using ideal weeks for six months already, so this caught me off guard. It took me a little bit to wrap my head around the idea of an “ideal week” and to figure out why she was even asking

You see, it wasn’t just a random question. The client was wondering if she should take into account how many team members would be working on the feature.  She was trying to compare ideal weeks to the velocity of the team and determine how the features would lay out for the release

I began my answer …

To define an ideal week for feature estimation, it’ll help to understand what an ideal day looks like. Let’s say an ideal day is a day where a team member has no distractions and can code continuously for eight hours, uninterrupted.  This would mean that an ideal week would be one team member, estimating features for eight hours per day, for forty hours a week.

Okay, great. That was easy. Now, let’s assume that you could actually remove all those pesky distractions. Is coding for eight hours straight, five days a week even possible?

Not really.

Studies have shown that, even uninterrupted, most people can get five to six hours of productive work accomplished in a single day; no matter how long that day is.

I remember days as a developer where code was just flowing out of me, similarly to how I’m writing this blog post.  However, I also remember days where I sat and stared blankly at my screen, kind of like when I was asked about ideal feature-estimation-weeks where my brain momentarily flat-lined.

So, assuming most team members are working/being productive for five or six hours a day, we can then assert that a week’s velocity may look like .5 or .6 of five days for one team member.

I’m going to use .5 velocity to make the math easier. It’ll take four people of equal abilities to complete two “ideal” weeks’ worth of work.  Using a model like this is easier and more efficient than analyzing who can do the work and what their ideal week looks like, because all we want at this point is a relative estimate of the work.  We aren’t detail planning or committing to a time frame. We are simply asking if it fits into a sprint.

Let me pivot for a moment….

Why do we go through this exercise?  Two reasons:

• To help develop a shared understanding of the feature
• To get an initial estimate of size to determine if we want to move into elaboration of this feature

We may “slot” the feature based on size and priority for context, but we are only at an approval stage at this point.  Basically, we are feeling out the feature to help the portfolio and program team with priority.

Once the feature has been approved and prioritized, we go into feature elaboration. We do feature breakdown or backlog grooming. Then we plan user stories into sprints.

Now must deal with reality.  Team velocity is that reality.

Usually, we can’t have all team members work on a single feature.  So, we are inclined to spin up another feature in parallel. This seems more efficient from a utilization standpoint, but as we switch to Lean thinking, our goal is to start and end work before starting the next piece of work.

 “In Lean thinking, we want to increase throughput not utilization.”

This is one reason why we ask that you don’t try to overanalyze the number of people in the ideal week – we don’t want that habit to propagate. Before you know it, you’ll be saying, “Tim is the only one that knows anything about this feature, so the ideal week is Tim for 4 weeks.”  Now you’re doing resource planning. If the team’s skillset doesn’t change, you will have historical ideal week velocity, just as you have user story point velocity for the delivery teams.  Left unchanged, the team’s velocity will stay flat and throughput won’t increase significantly.

Back to the original question. What is an ideal week, and do they even exist? They do exist if you are willing to redefine what ideal means to you. Ideal can no longer be defined as the dogmatic, fully utilized, forty-hour work week. Ideal must now be defined through the lens of throughput. Whether it fits into the sprint is the metric we’re looking for, not hours worked.

So, before you go asking yourself if you need to improve, you should always inspect before you adapt. You might just find that you are already estimating at a velocity that is realistically “ideal,” given your current resources and their ability to be productive.

For more information on why we want the team to focus on throughput and not utilization, check out Dave’s blogpost.