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 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 must 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 – 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, you will likely 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 team member 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 we will have the same result. And it also doesn’t guarantee that we will agree on what makes our requirements complete and compartmentalized.

This lack of agreement might seem problematic, but it’s not. This disagreement or difference of opinion 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 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 team member should be present, and you should have a set of categorized and prioritized requirements. Further, the requirements should flow logically – all dependencies should be identified and documented.

1. Begin by reading aloud the first listed requirement.
2. Each team member should secretly record the time they think it will take to complete the requirement. You can do this by jotting down your time estimate on paper using a common unit (e.g., half days or days), or with a deck of cards. In the latter case, each team member should select an estimate from a set of cards with predefined times (e.g., 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 done it.
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 them 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 document and discuss all assumptions and questions. This process helps identify new requirements, and clears misunderstandings.

Review Questions