To be in the moment (and I always like to be), here is a post for Halloween that removes the black magic from the estimation process and determines initial velocity.
Photo by euart used under the flickr Creative Commons license
Starting a new project and being around from the beginning is always an eye opener. If you are involved in estimation then it is also like signing a contract. Breach of promise to reach the guessed random number can be punished with overtime and a sense of failure. Heaven forbid a late project especially if it is fixed price.
I've started a new project and we are working out how long it will take and what resources are required. For the first time, estimation seemed more deliberate and less like guesstimation.
This is how we did it...
What you need to start estimating:
- The latest draft of the master story list - a list of the all the stories known so far, written like "AS a person using the system, I WANT TO do something functional SO THAT business value is achieved";
- As many members of the delivery team as possible - including engineers, testers (QA), business analysts (BA) and even business;
- Agree on the length of an iteration;
- An estimation deck - usually consisting of cards representing the Fibonacci sequence between 1 to 13. If you don't have this then use your fingers with 10 fingers = 13;
- A willingness to estimate in points and not days;
- A big table for everyone to sit around and to spread the cards on;
- Snacks - this can take a while.
- Sit everyone down at the table;
- Have the BA or Project Manager (PM) read through every story;
- Allow questions to understand what the story means;
- Rewrite or breakdown stories in to small functioning parts;
- Write out all stories on 4x6 cards.
- Re-read the stories;
- Get everyone involved in delivery to do min-likely-max estimates and write them on the back of the cards- minimum points if all goes blissfully well, likely points in a realistic situation and maximum points if all hell breaks loose;
- For each story work out volatility - low, medium or high;
- For each story work out completeness - complete, incomplete or unknown;
- For each story work out complexity - simple, medium or complex;
- Engineers group the stories in to what they think they could complete in one iteration. Use about 5 groups - dependencies and iteration order are not important. Just look at the size of the stories and group an iterations worth;
- PM secretly adds up the total likely estimated points from the groups and works out average iteration velocity;
- PM lays out different groups of stories that would fit in to the new predicted velocity - note this is not the teams actual velocity because that isn't known until they actually start banking points;
- The engineers looks at the groups and decide if they are too big, just right or too small - it's a little like Goldilocks;
- Rinse and repeat - this can be re-estimated and sorted again to double check numbers.
I liked the post. Here are some of my comments:
1. Don't attempt to do this with a huge backlog. If the estimation process becomes something that takes days, you are trying to do too much at once. If you won't get to develop many of those stories until weeks or months later, than don't spend a lot of time on them.
2. I agree with estimates in points and not days. This ensures the concept that points are relative. Especially early on, you can't say how long something will take, you can only rate the relative complexity - relative to the other stories being estimated.
3. I prefer a Pizza size estimation system, especially early on, where you have small, medium, large, and un-estimatable. The points for the sizes are 1,2, and 4. Once some velocity is established, you can begin averages of the numbers when developers vary on the given estimate, such as 1.5 and 3.
4. Clearly communicate that early estimates are not binding, they only serve to establish the ability to measure short-term progress and make future short-term predictions.
Post a Comment