Quickly explain how to make estimation work to an external business stakeholder

Question

Scenario: need to quickly explain how the estimation will work to an external business stakeholder; can't take more than few minutes really. The project area is web development.

P.S. There's no point in mentioning Agile, SCRUM and other terms that the business stakeholder doesn't really care about. All she cares about is producing "good" (or "decent") estimates so that she can, on her part, reasonably calculate project/feature cost and delivery time.

Here goes my outline:

Components for estimation

A component that should be estimated shouldn't be a feature, but should a deliverable: examples: "checkout process", "user registration"

• components can then be split into sub-components (for estimation's sake)
• e.g. SCRUM splits these into "epics" and "user stories"

Any deliverable should have clear "cut off" points that determine whether it's actually delivered.

When a feature is "delivered" it implies it is actually deployed (not simply sitting somewhere in some code repository) and delivers actual user benefit

Estimates themselves

When thinking "what to estimate" thinking about the following should help:

• component development effort (e.g. if you foresee there's a lot of manual work, or reading a lot of documentation, these increase "effort") - this is a "predictable" part

• component development complexity (e.g. if you know that developing this part is very tricky, comprising a number of edge cases, it will need a lot of testing, and therefore automated tests to be developed) - this is a "predictable" part

• component development uncertainty (maybe there's a better term) - this is the "unpredictable" part - if it is clear this part is inflating the estimate more than the "predictable" parts, then a "spike" should be conducted to make producing the deliverable more predictable, leading to a better estimate

  • what makes a given task unpredictable? Examples include: using an API you've never used/seen used by others before; a task requires a technical accomplishment which you haven't actually seen being accomplished by anyone so far, i.e. don't know whether it's possible, etc

• Any "deliverable" or sub-component thereof can be estimated at 1, 2, 3, 5, 8 where 2 is the "double" of 1 (obvious, but important to point out) any component that appears to be larger than 8 should be further split - this makes estimates less likely to be inaccurate

Any points I missed?

Answer 1

Delivering components is dangerous, because a component doesn't hold any business value and their late integration has a huge risk. Let's say I'm a business stakeholder, I don't want components, because I cannot sell them. Users want features, so do I.

You mentioned that you don't want to confuse the stakeholders with Scrum, but your outline is full of Scrum references. I don't really get it.

Stakeholders won't understand points (this is my experience). They understand two things: money and time. So, if I were I won't bother with points, efforts, complexity etc. Give them the following information:

• name, when will be ready, how much will it cost
• feature1.1, 5 days, 1000 USD
• feature1.2, 3 days, 2000 USD
• feature2, 6 days, 500 USD

(in the example above the stakeholders can make a decision wether they want to go with 1.1 or 1.2. It is up to them if they are willing to pay more to get the feature sooner.

I feel that your outline is too long, and complex. Imagine that you want to buy a car, and the sales person tells you about risks, complexity in the production flow. You are interested in two things: when you'll get your car, and how much will it cost you. Start with these, and if there are more questions, you'll update your document.

Answer 2

It might be better to talk about the assumptions underlying your estimates. Things like:

• The technical requirements delivered by the client are clear and complete. You need to be clear that estimating is to a large degree a garbage-in/garbage-out exercise.
• Project constraints in terms of scope/budget/schedule are known. If your business team has made promises in terms of delivery date or cost range or whatever you need to know.
• Desired level of error in your estimate. Based on what you know, what the requirements look like, etc will you give an estimate that is +-10% or +-100% or whatever?