High-Level Estimation

Hero image for High-Level Estimation

Introduction

The first thing to do when creating a high-level estimation is to try and avoid doing a high-level estimation altogether. If a high-level estimation is essential and heavily requested by the client, then please follow this guide thoroughly.

Why

The Nimble team’s approach to estimating work is based on developing a thorough knowledge and understanding. Only then can the team confidently assess the effort required to deliver a piece of software.

Product Managers and Engineers do a lot of legwork and heavily support clients with feature discovery and requirements gathering. However, there are times when the client cannot provide the answers that the team needs but still needs information to progress with the product roadmap.

What

A high-level estimation is an estimation of the effort required to deliver a piece of software without a deep understanding or precise requirements for the feature. It is based on a high-level understanding and historical knowledge of the project and risk assessment.

Risks

Why are high-level estimations such a dreaded topic? Because the risks associated with it are enormous. Typically, someone on the client side will take a Product Manager’s high-level estimation as a commitment, and the team will end up in a conflictual situation where the client expects an unrealistic delivery.

Clients will always say that they will not use a high-level estimation as a commitment, but nine times out of ten, they will for one reason or another.

Communication

The High-Level Estimation Communication Template is the only acceptable way to communicate a high-level estimation to a client.

By not using this template, Product Managers would dramatically increase the risks of conflict with the client. Product Managers are fully accountable for the high-level estimations that they share, so they must do this exercise with the utmost attention.

Any high-level estimation must be reviewed by a Lead Product Manager before being shared to the client.

“Feature User Stories”

Breaking Down Requirements

The high-level estimation approach everyone follows at Nimble is the “feature user stories.” What it means is that Product Managers must break down the high-level requirements into features while following the user stories naming pattern. For example:

  • As a user, I can register with Facebook
  • As a user, I can log in with Facebook
  • As a user, I can see my notifications
  • As a user, I can view the FAQs

Actual user stories, following the conventions, would be much more granular. However, in the context of a high-level estimation, this approach still offers a manageable level of granularity while providing clarity to the client about what is being estimated.

Estimating Feature User Stories

With the “feature user stories” breakdown done, Product Managers can make estimations.

Estimations must be done in sprints and not in an absolute unit of time such as man-days or man-hours.

For example (the “remarks” column is only intended at offering insights about the thought process):

Feature Remarks Sprints
As a user, I can register with Facebook Need to create and configure the Facebook application, return URL (to the application), terms & service page, etc. 0.5
As a user, I can log in with Facebook   0.5
As a user, I can see my notifications Think about receiving notifications, listing them, seeing the details, differentiating read vs. unread, etc. 1
As a user, I can view the FAQs Fetch FAQs from API, list all questions, see the details of a question. 0.5

If appropriate and necessary (but not mandatory), the sprints estimations can be broken down per application. Generally speaking, it is best to only separate mobile from web when needed without differentiating iOS and Android as there is usually parity between the mobile applications.

When doing a sprint-based estimation Product Managers should assume that the work will be done by the current team (i.e., the same number of developers).

Once all the estimations are done, the Product Manager should sum up the sprints and round up to the next integer. In the above example: 0.5 + 0.5 + 1 + 0.5 = 2.5 sprints, rounded up to 3 sprints.

Estimating Risk

The danger of high-level estimations lies in its risks. Risk estimation is difficult yet essential.

Looking at the Rumsfeld Matrix will give Product Managers more clarity about the risks inherent to the feature(s) that they need to estimate at a high-level.

One of the reasons behind Nimble’s very granular user stories breakdown is to reduce all the unknowns and risks to a minimum.

Rumsfeld Matrix

  1. Known knowns: those are the requirements that can actually estimate.
  2. Known unknowns:
    1. Definition: those are risks that can foresee and challenges that can anticipate.
    2. Mitigation: overestimation is needed. In the example from the previous section, “As a user, I can see my notifications” could take less than a full sprint if the final requirements are simpler. However, there are some unknowns: maybe needing a “read” indicator, maybe needing to archive notifications, maybe needing to highlight the unread notifications, etc.
  3. Unknown knowns:
    1. Definition: those are, for example, dependencies (e.g., third-party APIs). Their existence is acknowledged, but it is unclear how easy it is to use them or even if they provide all the necessary functions (although the Product Manager should investigate this).
    2. Mitigation: overestimate and put additional disclaimers in place (e.g., “assuming that service X’s API has the right documentation and allows for this function; should this not be true this high-level estimation would be impacted”).
  4. Unknown unknowns:
    1. Definition: those are the requirements that are not communicated and the possible blockers and bottlenecks associated with them.
    2. Mitigation: a disclaimer needs to be added with the high-level estimations stating that the requirements are too rough (i.e., leaving many unknowns).

High-Level Timeline

Ultimately, what the client is interested in is a time-based estimation. To get to that point, Product Managers must follow the same process as the sprint planning: based on the team velocity, assess how many feature user stories can fit inside a sprint.

Finally, the Product Manager will have a time-based, high-level estimation for the work requested.

For example, assuming a team of three Engineers who deliver an average of 30 story points per sprint:

Feature Remarks Sprints Sprint #
As a user, I can register with Facebook Need to create and configure the Facebook application, return URL (to the application), terms & service page, etc. 0.5 Sprint 1
As a user, I can log in with Facebook   0.5 Sprint 1
As a user, I can see my notifications Think about receiving notifications, listing them, seeing the details, differentiating read vs. unread, etc. 1 Sprint 2
As a user, I can view the FAQs Fetch FAQs from API, list all questions, see the details of a question. 0.5 Sprint 3

When sharing a high-level timeline with a client, Product Managers must not share the sprints estimation. Instead, they must only share the sprint number (reflecting both how many sprints are required and in which sprints the features would potentially be developed).

High-Level Man-Days Estimation

Product Managers must do this as an absolute last resort (i.e., if the client is somewhat blocked without a man-days estimation).

To get to a man-days estimation, assuming a 2-week sprints cycle:

Engineers * worked days per sprint * number of sprints necessary

Do not forget that design might be required as well.

In the example above, the man-days estimate would be (again, for a team of 3 Engineers):

3 (Engineers) * 10 (worked days) * 3 (sprints) = 90 man-days