Let’s Talk about Estimating our Points

Estimating Points in San Antonio

People are really bad at estimating how much time something will take. I always think I can estimate time, and I’m always inconsistent. I look at my 65 email messages, and I think, “That’s about an hour. A minute per email. I can do that.”

But reality is more complicated than I think it is going to be, even when I’m just doing email triage.

Scrum has a solution for that. People can estimate relative difficulty pretty well. I know cleaning out my email inbox generally takes less time than the full process for a staff newsletter. I know that the staff newsletter takes less time than a Laity Lodge newsletter. I know that a set of LLYC web requests is going to take even more time than that. That’s the theory behind point estimates.

Quick reminder: we assign points in a modified fibonacci sequence. Because we’re nerds.

The sequence is 1, 2, 3, 5, 8, 13, 21

1 — This is a quick task. Something that takes less than an hour. The sort of task that when I read it in my email, I jump to it. These tasks are the most predictable, at the center of my expertise, and also relatively simple.

2 — This is still a pretty quick task. In theory, I could knock out three or even four of these in a day if I have no interruptions and stay in the zone. Building a new page for a website might be a two if I have a clear idea for the design, a decent draft to start with, plus some images.

3 — Things are starting to get a little less certain. Maybe I’m drafting a post, but I don’t have any copy at all. Maybe the post has some complicated design elements. Maybe the post has multiple stakeholders. I can still get this done in half a day or less if I stay focused.

5 — We’re now looking at a more complex task. Something that is going to be the main focus for the day, though a day working on a 5 will still have margin. When I wrote the MLK story for the newsletter, it was a 5. The draft had some back and forth editorial with Patton. It required some research that started with Pam and ended with me in the archives vault myself.

8 — This task generally can’t be done in one day. Not because it isn’t technically possible, but because we have too many interruptions and less ability to focus than we think. An 8 requires extended focus. It’s the novella of tasks, something we’d like to push through in one setting, though we often need two or three.

13 — Now we’re looking at a complex task. Which means there is a lot of uncertainty. A 13 is often several smaller tasks that I just don’t know enough about. For instance, if I were to try to update all of the WordPress stuff that needs updating (a theme, WordPress core, several plugins), I’d estimate it at a 13. If I had done it before with this site, this set of plugins, this host, etc., it would be lower. But so many new systems mean I’m looking at two to three days of focused work.

21 — Whatever this is, it’s going to dominate my imagination for a full week. I’ll still be able to do other stuff around it, but it will require extended focus and discipline to avoid getting pulled away. Setting up a functional prototype of Bunk1 might be a 21 because it is going to require time, learning, some back and forth with the developers, testing with dummy accounts, as well as strategy. The more I push through this task, the more little things I’ll identify that I want to do. (“I can change the header! I can restructure these folders. I can load 8 years of content. Dagnabit, these are already showing up in CircuiTree user dashboards!?”) In truth, a 21 is usually a task that should be broken down into subtasks.

Our team doesn’t go bigger than 21. Our biggest tasks can have a cocktail, but mostly we’re teetotalers.

And just for grins, this: