Use meaningless techniques when sizing a complex project

— Note —
this is a rough draft, barely re-read, that I may reedit / republish one day. You may find misspells, incorrect grammar forms and unclear ideas made into twisted sentences. This is a desperate try to publish early and often instead of rethinking and rewriting my posts for month… then loosing the initial impulse to publish them.
—-
Collectivelly or individually, we seem to suck at evaluating complex project duration. We’re subject of numerous cognitive bias, such as optimism, social alignment on the leader, etc.

To succeed in sizing, I think the best approach I’ve seen working are the one that go round these bias, dodge them we could say.
Considering optimism, the baseline I use with agile teams sizing the remaining work : get numbers and global sum as later as you can. The evaluation has to be globally meaningless as later as possible. What you can’t see, like the full duration of the project you’re talking about, or the total sum of money it costs, can’t bias you.
Let me explain with concrete tips :
– use symbols, like t-shirt size or bike/car/truck/train/plane, or triangle, square, circle, etc. The less interpretable these symbols are, the less optimism can apply.
– compare and categorize work chunks by estimated size. Is X bigger than Y ? no, so it remains an « M » category
– as much as you can, try to compare every pieces in one batch. Dont evaluate pieces one by one, slowly, sequentially. Do it fast, evaluate in parallel, put aside the pieces that are problematic. I usually have all pieces printed and sort them physically on a table.
– use real references to compare to, so you keep an homogeneous scale month after month. Define piece of A as best representation of « S size », another piece of work B as example of « M » size », etc. Then when a new piece of work Z has to be evaluated, compare it to previous pieces of work A, B, and C. Not to meaningless symbols like « S », « M », « L », or too engaging-but-not-more-meaningful numbers.
– at the end, evaluate the references of each category with real numbers, like days, ideal man.day (erk), Euros, or complexity points as we use in agile. But let the math do the sum. Do not let that to a human brain.

Regarding leader bias and group bias, I use facilitating techniques to avoid polarity like
– use a facilitator!
– have people evaluate all at the same time on a first batch. Avoid one person taking the list of pieces and controlling the process, even for « helping »
– make people move physically around the evaluation table / wall /excel

More could be said on the whole process but I was willing to remain as less « agile-software development » oriented as possible.
Hope it helps.

Tags: Agile Facilitator, Agile Management, Agile Planning, Biais cognitif, Chiffrage, Complexité, Evaluation, eXtreme Estimates, Pilotage, Project Management, Release Planning, Team Practices