Imaging the following situation: your team is having a meeting in which you have to decide which features, components to build for next product or service release. Or by having a specification from system analyst you have to decide how long it would take to build the desired product so appropriate offer can be made to the client.
Either way it is very important what you will decide because all future changes will be around this very first decision. You are setting the expectations and this is very important for the project outcome.
One very popular technique is asking the developers for their estimation. Once the team leader has this number it multiplies x2 and gives it to PM. PM also multiplies it x2.5 so there will be good buffer zones. This approach, funny or not, somewhere works. And there are happy customers and ISV.
Yesterday I attended Seattle code camp and a very interesting session was “Agile Estimation Techniques” presented by David Starr.
| (image by old.crisp.se) ||The idea is simple: everyone from the team has a deck of cards. Having once already solved problem/built feature by the team is set as base one at well-known cost (in man-days, man-hours, ). Then another upcoming tasks is put on the table and after initial discussion everyone of the team lay the card of choice representing their thinking of the cost. |
If there are big difference if some team members’ choice let them discuss their choice and repeat until everyone pick closer costs.
Look interesting, doesn’t it?! Read more here: