Having spent a significant amount of our time categorizing and prioritizing the requirements, and further ensuring that they satisfy various internal dependencies, we have one final activity left before we can begin the process of planning the implementation of our solution.

Consider the following requirement (which you should recall from our section on specificity and measurability):

Take a moment to think about what you might need to do to implement this requirement; jot them down below.

How long do you think it would take you to implement this requirement?

Why do you think it might take this long? What assumptions have you made?

Each of us will more than likely come to a different interpretation of how long it should take to implement this requirement because we:

• have different coding practices and speeds,
• have different skills and experiences (so some of us might be very familiar with how to implement this), and
• assume different things about the requirement and what it means to complete it.

As a result, our team might have estimates that range from 10 minutes to 10 days (or more). How do we go about reducing some of this variation?

First, we need to recognize where we can and can’t reduce the variation. For example, the speed at which we code can only be controlled so much. Some people will naturally be faster than others, and our speeds will vary by day and context.

We also can’t control the experiences that our teammates have had. Some of them might have developed something similar in the past, so they can borrow from what they’ve learned to avoid pitfalls or mistakes, or to eliminate tasks that aren’t necessary.

However, we can – at least to some degree – control how everyone understands the context of the requirement. We do this using two things: completion and compartmentalization.

Completion & Compartmentalization

When you develop your time estimates for each requirement, it is very likely that you will assume certain things have been completed, or you might ask “Do I need to account for…?” and then list a series of things that might be essential to completing the requirement.

For example, given the requirement on the previous page, you might ask “Do I need to include the time it will take to build the entire database?”, or “Do I include the time it will take to build
only the parts of the database that are connected to this action?”

This uncertainty in scope leads to uncertainty in time estimates.

As a result, we try to restrict each requirement so that each member of the team generates a time estimate for the same thing. We call this completion. That is, we assume that everything else that needs to be completed has been completed.

We also compartmentalize. Specifically, we provide estimates only for the requirement – not for the requirement AND its dependencies.

Of course, this doesn’t guarantee that each of us is still going to come to the same result. And it also doesn’t guarantee that each of us is going to agree on what makes our requirements complete and compartmentalized.

This lack of agreement might seem like a bad thing, but it’s not. In many cases, this disagreement or difference of opinions as to what makes a requirement complete and compartmentalized allows us to identify other requirements we might not have originally drafted. It also helps clarify assumptions so that every team member understands what needs to be implemented and what doesn’t.

This is by no means an easy process. It requires patience and a lot of critical thinking.

Developing Time Estimates

The actual process of developing time estimates for each of the requirements is simple. However, don’t be surprised if you spend more time than you might imagine discussing time estimates for even the simplest of requirements.

Before you begin, every member of the design team should be present, and you should be working with requirements that have been categorized and prioritized. Further, the requirements should flow logically, with all dependencies identified and documented.

1. Begin by reading aloud the first listed requirement.
2. Each team member should secretly record the amount of time they think it will take to complete the requirement. You can do this by jotting down your time estimate on a piece of paper using a common unit (e.g. half days or days), or you can use a deck of cards. In the latter case, each team member should select an estimate from a set of cards with predefined times on them (such as 0 days, 0.5 days, 1 day, 2 days, 4 days, 8 days, etc.). Regardless of the method, keep your estimate to yourself until everyone has made their choice.
3. Everyone should reveal their answers at the same time. Be prepared to justify your selection.
4. Repeat steps 1 through 3 for each of the requirements. Should a requirement have dependencies, review the dependencies so
   that everyone is basing their estimates on a complete and compartmentalized view of the requirement.

What do you do if everyone agrees on the time estimate? Or worse, what if everyone disagrees?

The answer is to simply document and discuss all assumptions and/or questions. This process helps identify new requirements, misunderstandings, or things that not everyone has thought about.

Review Questions