Internal: Estimating Projects: Difference between revisions
John.meegan (talk | contribs) mNo edit summary |
John.meegan (talk | contribs) mNo edit summary |
||
| Line 15: | Line 15: | ||
Include estimates for: | Include estimates for: | ||
* '''Writing requirements documents''' - if not already done | * '''Writing requirements documents''' -- if not already done | ||
* '''Coding''' | * '''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. | * '''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. | ||
Revision as of 05:01, 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 -- "release testing" at the end