(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)
(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).
Let’s talk estimating how much work something takes. This may sound boring, it will get abstract, but stick with me here – it’s pretty interesting.
I’m using the Agile method of Scrum in my own life, which involves sizing work to know how “big” it is. If you’re not familiar with Agile practices, just know this is an area where pros argue a lot, so if you think we’ve got it figured out, you’re wrong.
I size my personal work in terms of hours to complete because I’m self-aware enough to get those estimates reasonably right. It’s not perfect, and I wanted to get better. I think I found a solution while reading The Elements Of Scrum as a refresher, because the authors explained the challenges of sizing work better than I’ve ever seen.
Again hold on here, because we got some backstory.
In Scrum (and related methods) work is often sized in abstract points – the smallest piece is a one point, something twice the size is a two, and so on. Then people figure out how many “points” of work they can do in a given time – and this often works very well (I’ve seen new teams get it 80% right out of the gate).
Why does this work? Because people are great at relative sizing (this is twice the size of that thing) but not so much at doing specific time estimates. Leverage this ability and people get an idea of how big (or small) work is, and they can then do a decent job of figuring what can be done in a given time. Sort of zooming from general to specifics.
Sounds simple? It is, but many Scrum practitioners require points to be in the Fibbonacci sequence – 1,2,3,5,8, and so on. So something twice the size of “1” is a “2” – but if something is twice the size of a “2” you have to call it as more likely to be a “3” or a “5.” Sound weird? There’s a reason.
The author explained it simply that drove this point home:
- People are good at comparing the sizes of small things but have trouble with larger things. This applies to time take to sizes of physical objects and more.
- #1 gets worse the larger the things being compared are.
- You use the Fibbonachi sequence as the range between “allowed” sizes gets larger and larger, forcing you to make a judgement call and giving you a bit of buffer.
Where does this come into my time estimates? Well my time estimates weren’t bad, but they weren’t great. I also didn’t want to use points as some of my “life stuff” was far better measured in hours. So I started using Fibbonaci sequencing to estimate hours of work because this simple explanation made me realize I’d falsely thought I could estimate large stories as easy as small.
So right now the smallest piece of work is one hour – but I can’t say something is six hours, I have to ask if it’s more likely to be 5 or 8. Sure there’s probably over and under-estimation but it evens out.
I started doing this late June and in full this July – and it was an eye opener:
- In larger pieces of work, had I used Fibbonachi numbers on big things, those would have been more accurate. Yes, some of my estimates were worse when I tried to be specific instead of using some constraint like “is it closer to 5 hours or 8”
- Some of my fiddly little estimates (45 minutes, 90 minutes) were less accurate than their Fibbonachi counterparts.
- My best estimates happened on things that were 2 to 3 hours long – fortunately the majority of my work. However there was enough “mis-estimation” in large and small items to probably throw off my monthly estimates by around 10-20 hours.
- Items that were 8 hours or more were a warning sign to break things down – those were often woefully inaccurate and hard to work with.
- Items that I did break down usually surprised me – there was often more work than I thought. Breakdowns (again, using Fibonacci) were more accurate.
I’m going to be sticking with Fibonacci hours for now – maybe you want to try this in your own life, even if you’re not using Scrum or Agile techniques.
(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)
– Steve