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
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?