Vanguard Coder

Simple Life of a Keen Developer

Agile Projects:Scope & Estimation

one comment

In Agile developments, the scope line of burn-down charts should never go up unless it is a planned (removing other similarly estimated stories, or adding more resources to the team) addition of requirements to the project. If there are estimates that are bad:

1) If the wider project is believed to have incorrect estimates, then, the entire work should be re-planned, otherwise there is a huge delivery risk, i.e. The entire team having to consistently throughout the project work long hours (developer productivity is limited to a few hours a day and it is unlikely 10 hours of pair programming could work), or having unachievable velocity requirements. However, this is a benefit as this is determine within the first 2-3 iterations (hopefully they’re 2 weeks).

2) Scope line should be progressing by increasing the estimates of the stories that have lower estimates (if some estimates were wrong), but at the same time removing “Would haves” or “Could Haves”

3) It should be looked at on what was missed (e.g. consistently leaving out acceptance test scripts) for the stories to be estimated or a ‘Safety Check’ (used in retrospectives)  to allow the facilitator to check if the developers will be open and honest about estimates.

 

Written by zkashan

May 26th, 2012 at 10:15 pm

Posted in Project management

One Response to 'Agile Projects:Scope & Estimation'

Subscribe to comments with RSS or TrackBack to 'Agile Projects:Scope & Estimation'.

  1. Hi,

    I’m not sure if you are really doing Agile if all the estimates are done upfront – doesn’t that make your project waterfall?

    In any case, we did publish (on PM Hut) an article on agile upfront estimates – hopefully you’ll have the chance to read it.

    PM Hut

    28 May 12 at 4:57 pm

Leave a Reply