Stop using story points and estimating purely based on complexity. Start using coffee points instead.
Those working in an agile environment traditionally use story points to estimate the complexity of a task, which is then used to figure out roughly how many stories will fit in a sprint. Evangelists of this method say that estimating based on time is bullshit that forces programmers back into working for The Man with unrealistic deadlines instead of self-organizing themselves.
Aside: If you're using agile in its original form for software development with actual releases, you may not need to read further. The trend nowadays is to shove everything into agile mode, which gets more tricky when your software is something like an ever-evolving website without defined increments. Or when the bosses decide that the accounting team should also be agile.
The reality is that estimating complexity in a real-life environment is insufficient. Sometimes there’s a task that someone has to do, and it’s boring and simple and not complex, and it will take forty hours, give or take. But if estimated purely by complexity, it’s a one or a two – a monkey could do it. We can do twenty story points in a sprint, thinks the product owner, so ten of these tasks will fit. The planning meeting devolves into sniping about complexity versus time, or about dragging down sprint velocity because we can only realistically do three of these 40-hour, 2-point tasks.
What’s that? You’ve only worked in places that estimate complexity and it works without any arguing? Have a medal.
The other problem with story points is a motivational one. When working on a cross-functional team that is not just developers, I’ve seen a tendency for the programmatic tasks to be rated as very highly complex and other tasks, perhaps fairly, to be rated low. The task to go through all the 404s and check if they’re legit? It’s legitimately boring. But it leads to the SEO team member having, say, 4 story points per sprint when the programmers are rocking 20. It’s not good for morale.
So instead, ask the question, “How many coffees will I need to solve this?” Your team will need to align on how many coffees it takes to wake them up, but here’s my example:
- A simple task that doesn’t take long – I can do it while sipping on my first coffee of the day. 1 point.
- A quick task that requires thinking – I won’t even start this until after my second coffee of the day. Minimum 2.
- The next task is small but quite complex. I’ll need another coffee in the afternoon to jump-start my brain. 3.
- Here’s a task that isn’t complex but is lengthy. I’ll need a few days to do it, so at roughly two coffees a day, that comes in at 8.
- Ah, look at this super complex project that really should be broken down into smaller parts but the team’s not that advanced yet. Gonna need a lot of coffee. 20 coffees: if I put all my time into it, drink some extra coffee, I can get it done in a week. Or I take my time and finish in about ten days.
Coffee points are a more intuitive way to balance time and complexity when evaluating tasks in a cross-functional team which often deals with less complex but time-intensive tasks.