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.
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.
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.
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.
“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):
|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|
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.
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.
- Known knowns: those are the requirements that can actually estimate.
- Definition: those are risks that can foresee and challenges that can anticipate.
- 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.
- 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).
- 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”).
- Definition: those are the requirements that are not communicated and the possible blockers and bottlenecks associated with them.
- Mitigation: a disclaimer needs to be added with the high-level estimations stating that the requirements are too rough (i.e., leaving many unknowns).
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:
|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|
High-Level 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
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