So I’ve got these books.
I left off my discussion of how I track projects by saying that a book that takes me two to three hours to read is worth one point.
For example, here’s a one-point book.
How do I know that reading these books are one-point projects? Because they took me roughly the same time to read as my benchmark.
Here’s a pair of two-point books.
Again, I know that these are in the two point range because they took me between four and six hours to read, roughly twice the time for the one-pointers.
These are three point books.
How do I know that? Estimating. I’ve spent a little time with each of them1, and I know they’ll take me a little longer than the two-point books.
How big is the other book?
I estimate this at five points, because it’s going to take me a little longer to read than the three point books.
Wait a minute, you may be thinking. If it’s only a little bigger than the three point projects, why isn’t it four points? It isn’t because I don’t have four-point projects. I use a Fibonacci sequence for estimates, for reasons I’ll explain in a minute. What I’m really saying is that Practices for Scaling Lean & Agile Development is the next size bigger than Working Effectively With Legacy Code; it’s just that the steps get progressively larger as the projects get bigger.
So why do I use this complicated scheme rather than estimating hours? Two reasons. First, it means that I’m using relative estimation. Humans are pretty bad at absolute estimation, but pretty good at relative estimation. We did an exercise in my Certified Scrum Master class where we were asked to order ten items by price, including things like a golf club, two nights at the Venetian in Las Vegas, and Audi R8. Despite not being able to produce accurate estimates about the actual cost of things, we were able to put them in pretty much the right order, and we even got the ratios between some of them roughly correct. By using relative estimates, I can say, “Farewell, My Lovely is going to take me about as long as The Big Sleep” have a pretty good chance of getting it right.
The second reason is that using Fibonacci numbers avoids false precision. Our ability to estimate, especially in time, gets worse as the things we’re estimating get bigger. Even when we use relative estimation, it becomes harder to get the ratios right. By using a fixed sequence, I lock down the possible ratios. The Fibonacci sequence is particularly good because of the way the distance between the steps increases as the steps increase.2 I don’t worry about whether something is an 11-point project or a 14-point project; they’re both 13s. Remember, at that point I’m dealing with something that will take me more than 20 hours to get through3, so any precision I think I can capture is probably false. And in the aggregate, things work themselves out.
So that’s my basic method, and while I’ve talked about it in terms of reading books, it’s easy for me to relate it to other projects as well. Writing the first draft of a 1500-word short story? It’s a 1-point project. Watching the entire Tour de France? It’ll take me 20 points.4 How do I know these things? Because I can relate them stuff I already know.
So the last step in this approach is measuring what I can accomplish in a given period of time. That’s coming in the last post in the series.
1 In part to figure out if I want to read them.
2 You could probably get results just about as good if you simply doubled at each step: 1, 2, 4, 8, 16, etc.
3 Because otherwise it would be roughly 8x of my 1-point projects, which take 2-3 hours, remember?
3 Yes, technically it should be 21, but I tend to do 1, 2, 3, 5, 8, 13, 20, 40, 100 rather than the strict Fibonacci. It comes from my training.