If you ever worked with me you would know I’m not a big fan of estimates, mostly for the reasons better explained here, here and here, but there are still moments within a project where there are a bunch of stories written and teams need to have a guess on how much time will be needed
- the project might be beginning and we need to know what is realistic or not
- there might be go to market activities that need to be synchronised in advance
- there might be a fixed deadline and we need to understand if there is any chance of making it or not
In cases like these, I’m still not a big fan of using planning poker or similar practices. First of all, it takes a _lot_ of time. Whoever has experienced a long session of estimation can probably remember people rolling their eyes as soon as we get to card number 54 (or around that…).
And handling the short attention span of tech people (which could probably be increased for the better) is not the only problem here. In every project there will be a lot of similar cards, and reestimating similar things over and over is probably not the most productive thing a software team could be doing, and also tests the patience of anyone involved.
Instead, what I’ve used in the past is a simple technique for group estimation (that I’m sure I saw somewhere before, so don’t credit it me for it) that will allow a group to get to some numbers with less time and effort.
1. Write all the stories you have in cards, and put them on top of a table.
2. Create 3 separate areas within the table, based on different timeframes. What I normally use is 1-5 days, 1-2 weeks and “too big”.
3. Ask the team to go over the stories and position in the categories they find appropriate. Let individual people move (and move again) cards however they want for a few minutes.
4. Let everyone go through the table and look at the cards, and observe the ones that are being moved between categories frequently.
5. Get the unstable cards and the ones in the “too big” category and discuss them within the team. Rewrite cards as appropriate.
6. Rinse and repeat if needed.
Is it precise? Probably not that much. Are any estimates precise? Definitely not. So far every time I’ve used we got a good level of results that were in the right timescale, which is probably the most you will get from software estimates anyway.
Regarding the fact that every story is not individually discussed within the team, a common argument in favour of detailes estimates, I believe there are better times to do that than when looking at all the cards with no context or experience working on them. Time to establish some story kick-offs maybe?