Agile working is all about doing the right things. First do the things that take the least time (low impact) and at the same time deliver the most (high value). The product backlog is ordered that way. Estimation – yes, agile is peppered with Anglicisms – is not easy, however. On this page a few tips.
ESTIMATING WORK IS DIFFICULT
We humans are good at relative estimating (‘An elephant is bigger than a mouse’) but bad at absolute estimating (‘An elephant weighs x kilos, a mouse only y’). In agile, estimates therefore have a relative character.
This means that you first choose a benchmark. A well-developed task or user story counts as the average with which the other items are compared. The key question: ‘Is this task more or less work than the benchmark’? We do not use hours for this, but relative units. Below a number of techniques to estimate size relatively.
SIZE ESTIMATE
There are several techniques for estimating the size of items. Again, these are relative estimates.
- Planning poker`*
This is the best known way to estimate the size of PBIs. Sometimes also used for determining value. There is enough written and known about this, but for those who want to know more . - T-shirt sizing
No Fibionacci series as in planning poker, but t-shirt sizes. from XXS to XXL. Also known, so more behind this link . - Hand voting
No planning poker cards to hand? There are five fingers on the same hand. Including the fist, you have 6 variants. One fist means totally disagree and five fingers totally agree. count down ‘1… 2… 3…’ and raise your hand at the same time. Be sure to discuss the extremes (and watch out for the jokes that the hitler salute brings).
* For Zoom en Teams sessions you can use an online tool for planning poker.
Create a first backlog
Are you starting with scrum? Then create a first product backlog. a very handy and fun technique for this is Magic Estimation . Barry Overeem explains the method clearly here .
Do you have fun or better ways for estimation, email them!