Revision as of 04:18, 1 March 2016

Estimating Projects

For one issue you’re almost never going to get it right, but for groups of work our estimates get better because if say 90% are done earlier than estimated, and 10% blow out, the overall amount is about right. So if you provide a “bit” of slack for each issue then you should be safe.

It is useful to group issues into 3 pools, then estimate issues individually based on these:

Hard
Medium
Easy

Include estimates for:

Writing requirements documents - if not already done
Coding
Testing & Rework -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
Validation

Developer Home

@@ Line 6: / Line 6: @@
 = Estimating Projects =
+For one issue you’re almost never going to get it right, but for groups of work our estimates get better because if say 90% are done earlier than estimated, and 10% blow out, the overall amount is about right. So if you provide a “bit” of slack for each issue then you should be safe.
 It is useful to group issues into 3 pools, then estimate issues individually based on these:
@@ Line 17: / Line 19: @@
 * '''Testing & Rework''' -- there’s no general rule for this.  Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
 * '''Validation'''