Ideal Days: Quick and Adequate Estimation

An agile team’s goal is to produce valuable software. Spending time perfecting estimates is as wasteful as oversleeping.

What is meant by ideal days?

In Essential Scrum, Kenneth Rubin defines idea days as:

“A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions, and all resources necessary to complete the work were immediately available.”

I remember my mom receiving a recipe for Amish Friendship Bread when I was young. This gross-looking sandwich bag full of gunk was “gifted” to her by a “friend” along with a series of directions she should carry out over two weeks. Each day for approximately ten days, there was some quick interaction she needed to do with this goopy concoction. Most days, she just had to smoosh around on it for a few seconds. But a few times, she had to add ingredients to the bag.

On the tenth day, the substance spawns other starters, like a wet gremlin.

From beginning to end, this process took ten days. But on most days, the effort took thirty seconds or less. Mom spent most of the time waiting and, thus, was free to continue her daily life while this goo did its thing.

If we were to provide an estimate for making Amish Friendship Bread, we’d say this is one ideal day. Although there are waiting periods included in the process, the actual effort takes place in less than a day. We’ll not be staring at the bag of goop for ten days. While not interacting with it, we’re free to spend our time accomplishing other activities.

In Agile Estimating and Planning, Mike Cohn eloquently differentiates ideal time and elapsed time.

“Ideal time is the amount of time that something takes when stripped of all peripheral activities. Elapsed time, on the other hand, is the amount of time that passes on a clock (or perhaps a calendar).”

Since we primarily use estimates for planning purposes, we want to focus on ideal time and not elapsed time.

Advantages of Estimating in Ideal Days

Low Barrier to Adoption

As humans, we’re already used to estimating in time units. We ask how long it will take to be seated at a restaurant. We ask how long it will take to get our oil changed. We ask how long it will be before our turn for a haircut.

Estimating how long it will take us to finish our work in time-based units is not a foreign concept. We won’t need to retrain the team, establish a crosswalk, or select a baseline story.

Faster

The imprecise nature of ideal days makes it easier for the team to decide on a round number.

When we pressure an agile team for precise estimates, they’re more likely to suffer from analysis paralysis. Debating and deciding between .25 days or .75 days might take an hour, and the team would better spend that hour creating valuable software. The more concerning thing is that the extra time wasted in estimation doesn’t guarantee that our estimates are any more accurate.

When we round everything up to whole numbers (days instead of fractions of days - or hours), we effectively remove some of the pressure for precise estimates. As a result, we’ll also be able to provide estimates faster.

Easier to Explain

Though ideal days have disadvantages when it comes to stakeholder communication, explaining the concept to stakeholders is much easier than explaining story points or t-shirt sizes.

As the team has been accustomed to estimating things in terms of time, so too will stakeholders expect estimates to be expressed in terms of time.

Disadvantages of Estimating in Ideal Days

Inconsistent Measures

You’d probably get a different answer if you asked me to describe my ideal day and then asked Hermione to describe her ideal day.

Inconsistency in what team members consider an ‘ideal day’ will plague this estimation approach. The same task might take Harry two ideal days, whereas Ron thinks it would take him three ideal days.

Another example of ideal day differences might be if Harry and Ron work different shifts. If Ron works eight-hour days and Harry works 10-hour days, this might skew their perception of how much work they can complete in a ‘day.’

The team could define ‘day’ in terms of hours to normalize these conversations, but it would still be hard not to be influenced by what you can typically accomplish in your shift.

Leadership Takes it Literally

In an article covering the origin of story points, Ron Jeffries describes the communication struggles with ideal days:

“We spoke of our estimates in days, usually leaving “ideal” out. The result was that our stakeholders were often confused by how it could keep taking three days to get a day’s work done, or, looking at the other side of the coin, why we couldn’t do 50 “days” of work in three weeks.”

The crux of the miscommunication boils down to the fact that there is no such thing as an ideal day; there will always be meetings and interruptions. By referring to time estimates in ideal days, stakeholders incorrectly associate ‘ideal day’ with ‘work day.’

Although the difference here should be obvious, it can be hard to explain to stakeholders. Some will ask why we don’t estimate in actual time, but unfortunately, I’ve yet to meet a developer that is also an oracle.

Works Consulted

• Agile Estimating and Planning
• IdealTime
• Ideal Day Glossary
• Story Points Revisited
• Essential Scrum: A Practical Guide to the Most Popular Agile Process

TLDR

Using ideal days as your team’s method for estimating size can be an easy way to get started with estimation.

Though no estimation approach is perfect, some alternative methods (i.e., t-shirt sizes and story points) can be convoluted or complex. Choosing an alternative approach based solely on the assumption that one is more accurate than the other can signify cultural issues. Similarly, sleeping fifteen hours a day is not only a waste but can also be a sign of an underlying health issue.

Since the number one priority for agile teams is to deliver working, valuable software, spending more time than necessary on estimation keeps us from our true goal.

The primary benefit of estimation is that it helps facilitate planning. If stakeholders ask the team to establish accurate timelines, they may benefit from training on the uncertainty of forecasts.