By this point, we have:

• Developed a list of requirements;
• Categorized them using the MuSCoW Method;
• Assigned priorities; and
• Identified dependencies.

We are now ready for one final step before building a development timeline.

We need to estimate how long each requirement will take to implement.

At first, this may seem like a simple task.

In practice, it is often one of the most challenging parts of software planning.

Why Is Estimating So Difficult?

Consider the following requirement:

A member of the sales team should be able to query the system to export a CSV-formatted table of their active customers sorted by company name in ascending alphabetical order in 60 seconds or less.

Take a moment to think about how you would implement this requirement.

What tasks would you need to complete?

How long would it take?

Now imagine asking five members of your team the same question.

Would everyone give the same estimate?

Probably not.

One person might estimate half a day.

Another might estimate two days.

Someone else might suggest an entire week.

Who is correct?

Perhaps all of them.

Why Do Estimates Differ?

Time estimates vary because people bring different experiences, assumptions, and working styles to a project.

For example:

• Some developers naturally write code more quickly than others.
• Some developers have solved similar problems before.
• Some people assume additional functionality is required.
• Others assume much of the necessary infrastructure already exists.

As a result, differences in estimates are completely normal.

The goal is not to eliminate every difference.

The goal is to understand why those differences exist.

What Can We Control?

There are some sources of variation that we cannot easily change.

For example:

• Individual coding speed;
• Previous programming experience;
• Familiarity with particular technologies.

These differences are part of every software team.

However, there is one important source of variation that we can reduce:

Our understanding of the requirement.

If every team member is estimating slightly different work, we should not expect similar estimates.

Creating a shared understanding of the requirement often reduces variation more effectively than trying to improve estimation skills.

Two Important Ideas

To improve consistency, we use two related concepts:

• Completion
• Compartmentalization

Together, these help ensure that everyone is estimating the same piece of work.

Completion

When estimating a requirement, we assume that everything required outside that requirement has already been completed.

For example, suppose you are estimating the CSV export requirement.

Should your estimate include:

• Building the entire database?
• Creating user accounts?
• Designing the user interface?
• Implementing login functionality?

No.

Those tasks belong to other requirements.

When estimating a requirement, we assume that everything else the requirement depends upon already exists.

This allows everyone to focus on estimating the same work.

Compartmentalization

Closely related to completion is the idea of compartmentalization.

Each requirement should be estimated independently.

In other words, we estimate:

• the requirement,

not

• the requirement plus all of its dependencies.

Suppose a reporting feature depends on user authentication.

The authentication work should already have been estimated as part of the authentication requirement.

It should not be counted again when estimating the reporting feature.

This helps prevent work from being counted multiple times.

Why Discussion Matters

Completion and compartmentalization do not guarantee identical estimates.

Nor should they.

If two team members estimate the same requirement very differently, that difference is often valuable.

It may indicate that:

• Someone interpreted the requirement differently.
• An important assumption has not been discussed.
• A dependency has been overlooked.
• A new requirement may be needed.

In this way, estimation becomes another opportunity to improve the team’s understanding of the system.

The discussion is often more valuable than the estimate itself.

Estimating as a Team

The process of estimating requirements is relatively simple.

The conversations that follow are often the challenging part.

Before beginning, ensure that:

• All team members are present;
• Requirements have been categorized;
• Priorities have been assigned; and
• Dependencies have been identified.

Then repeat the following process for each requirement.

Step 1

Read the requirement aloud.

If the requirement has dependencies, briefly review them so that everyone is estimating from the same context.

Step 2

Each team member independently records a time estimate.

Keep estimates private until everyone has finished.

Teams may record estimates using:

• Paper;
• Sticky notes;
• Digital tools; or
• Planning Poker cards.

Regardless of the method, everyone should use the same unit of time.

In CIS3750, we typically estimate in half-day or full-day increments.

Step 3

Reveal all estimates simultaneously.

Avoid allowing early estimates to influence later ones.

Independent estimates encourage more honest discussion.

Step 4

Discuss the reasoning behind each estimate.

Rather than asking,

“Who is right?”

ask,

“Why are our estimates different?”

This question often uncovers assumptions that had never been discussed.

Step 5

Repeat the process for every requirement.

What If Everyone Agrees?

If everyone produces the same estimate, that is encouraging.

It suggests that the team has a shared understanding of the requirement.

However, do not immediately move on.

Take a moment to discuss why everyone agreed.

You may discover assumptions that everyone is making without realizing it.

What If Everyone Disagrees?

Disagreement is not a sign that the process has failed.

It is often evidence that the discussion is working.

When estimates differ significantly, ask questions such as:

• What assumptions did you make?
• What work are you including?
• What work are you excluding?
• Did you interpret the requirement differently?
• Are you assuming another requirement has already been completed?

These conversations frequently identify:

• Missing requirements;
• Missing dependencies;
• Ambiguous wording;
• Unrealistic assumptions; or
• Opportunities to simplify the design.

Every disagreement is an opportunity to improve the requirements before development begins.

Estimation Improves Planning

No estimate will be perfect.

Software projects are filled with uncertainty, and unexpected challenges will always arise.

The purpose of estimation is not to predict the future with complete accuracy.

Instead, estimation helps teams:

• Understand the relative size of different requirements;
• Develop realistic development schedules;
• Identify requirements that should be broken into smaller pieces;
• Discover hidden assumptions; and
• Improve communication within the team.

Throughout CIS3750, remember that estimating time is not simply about assigning a number.

It is about building a shared understanding of the work that lies ahead.

The estimate is important.

The conversation that produces it is even more valuable.