The Burrito Method of Task Estimation
When building a new agile team, the process of aligning on the value of a story point can sometimes be tricky. As such, I’ve devised a simple process for getting started.
The main question is:
How many burritos could you reasonably eat before this task is completed?
1 Burrito (1 Point): You can basically complete the task with one hand while eating a burrito with the other hand. These are things like minor code changes.
2 Burritos (2 Points): A normal-sized task that will take you anywhere from half a day (so a lunch burrito and a dinner burrito) to two days.
3 Burritos (3 Points): Slightly larger task that might take up to 3 days or so. Realistically this won’t get done in a single work day unless you’re having a breakfast burrito.
5 Burritos (5 Points): Pretty big task. There should be some serious consideration to whether this task can be broken down, or if more clarification is needed to remove uncertainty (which might be why the estimate is so high). This is likely not a task that’s done in a vacuum, and could involve collaborating with others. Bring nachos to the work session.
8 Burritos (8 Points): This is almost certainly too big. Eating 8 burritos in a row is not recommended. This is a task that, if not broken down and further clarified, will likely take over a week to implement.
Tasks can get higher point totals than this (in fib sequence, probably) but 1) should not be brought into the sprint until they’re broken down and 2) should be considered rough estimates since there’s likely missing dependencies/context.
The exception to this is groups of tasks that need to be shipped together, such as building an entire page instead of just adding a component to one. In this case, there should be a parent task with child tasks that are at most 5 points each.
NOTE: the mention of “days” is the time it takes to get to DEV DONE. This doesn’t include QA time. In my mind it also doesn’t include code review, but I think it very easily could (and maybe should?).
QA Points
One thing that can be improved about most task estimation systems I’ve used in the past is the fact that one number is supposed to represent the dev effort, code review effort, and the QA effort. That’s not always accurate — a small change to a checkout page might be easy for a dev but require working through the entire checkout flow for QA. Thus, I propose that each ticket should get an associated QA effort pointing system. As you may have guessed, these shall be known as Quesadilla Points. My guess is that most of the time a task will have a higher Burrito Point total than a Quesadilla Point total.
Code Review Points
I kinda think this could also be a thing but 1) I don’t know if there’s an easy way to measure it because it’s a little bit more asynchronous than “I have this task I need to work on and I’m gonna work on it until I’m done” and 2) I can’t think of a good food reference for it. Chips and salsa? Maybe tacos because they’re kinda like smaller burritos?
Why this method?
It helps meld together the benefits of estimating effort (it’s pretty hard to eat 8 burritos) and estimating time. Dev work shouldn’t be estimated in hours because it’s far too constricting, but stakeholders still need to have an idea of how long implementing something might take. This allows things that need to go out before the end of a two week sprint to rise to the top while easily managing expectations of how much time and effort is involved.
So how many burritos should you eat in a two week sprint?
Probably a minimum of 5 and a target of 10. One should aim to eat all of the burritos they commit to. Realistically a team lead should probably order less burritos because they’ll be in way more meetings and doing more ad hoc stuff that doesn’t get accounted for very well (although I guess we could also track that kind of effort with Enchilada Points or something).
How many quesadillas should QA eat in a two week sprint?
Still probably a minimum of 5 and a maximum of 10, but they’ll probably have more tickets overall. You could also get creative with where the points get applied. For example, you could have a parent ticket that says something like “Add this piece of content to the home page”, and it has child tickets for the front end work and the back end work. You’d apply burrito points to the child tickets, and quesadilla points to the parent ticket.
