When you are planning your iteration/sprint/development cycle, use only the following estimates for the stories/features/PBIs.

Length	Use
Two hours	usually for cosmetic changes
Two days	(hopefully) most work because its been well scoped
Two weeks	for work you can definitely fit into the iteration
Too[1] long	signal bad requirements

Impetus

I tend to live by the following maxim:

My rules for me.

This means that I don’t like imposing my ethics on other people. That leads to a certain myopia about sharing my software development survival techniques.

A couple of months ago, a company had hired me to help develop some content for an agile transformation course they wanted to teach. Whenever I’d pick up a new assignment, the full-time author/instructor and I would usually chat about our experiences and perspectives on the subject to come to an agreement on the material I would prepare.

I had pulled the story estimation assignment from the backlog. This led to a conversation about “the planning game”.

I said, “Personally, I don’t like estimating. Hours, points, whatever. It led me to develop the ‘twos’ scale that I encourage my teams to use during planning: two hours, two days, two weeks, too long.”

He said, “I’ve never heard that before.” He mulled on it for a minute. “I think I’m going to use that. Have you ever posted that anywhere?”

Here’s that post.

Rationale

Let’s start off with some fundamental beliefs that I hold to be self-evident.

1. People are really bad at estimating.
2. Customers don’t care about velocity.
3. Developers dislike bookkeeping.

You may not disagree with those. I’m going to spend a little time writing about them. If you want, feel free to skip to the next section.

Tomorrow is so far away

I’ve been developing software for nearly 30 years. Even now, I find myself having a hard time estimating things.

Take this blog post, for example. I’m “writing it forward” or “pantsing it”. I know what I want to write about, but I didn’t put much thought into the structure and details. As I write it, I’m hopping all over the blog post, filling in arguments, writing explanations. (At this moment, I’ve come back to write this paragraph after having written the next six.)

Originally, I thought to myself, “Take an hour, write up the twos thing, be done.” The hour mark passed about an hour ago. For me, pantsing it takes more time than I originally imagined.

We face that with user stories, too. Who has design sessions before the planning/estimating step? Usually, no one, if they’re practicing Scrum or XP. (Everyone, if they’re practicing FDD. So, no one.)

Given that we don’t take time to do some kind of design, we have to make the “educated guess”. So, what’s the guess? One point? Six points? 6.25 points? (Yes, I’ve seen a shop use fractional amounts in planning.)

Practices like Planning Poker are meant to help with the first item. It limits your choices of available options for the number of points that you can assign, usually chosen from some kind of Fibonacci sequence.^[2] It helps overcome the so-called “paradox of choice”.

Let’s assume, though, that we get past that first hurdle, that we can use story points to estimate items in the backlog with amazing expertise. Those points lead to a new metric: velocity.

Velociraptors

Velocity. It gives a visceral feeling of movement and progress toward a destination.

I’ve stated this before (and will continue to state it) until I stop developing software: A project plan, any project plan, is merely an illusion of control.

Most customers really want a project plan. They want to know when it will be done, for varying definitions of “it” and “done”. Who can blame them? They’re not software developers. They’re not existential relative point system adherents. No, they’re simply people that want to have some working software that has all of the features they think they need.

We use velocity to plot burn-down and burn-up charts to present to customers and managers to give them a sense of “when we will be done”. We enable their illusion of control. Shame on us.

Ron Jeffries gives best answer that I know of for “When will it be done?”

But, we point to our velocity-based charts as if those are some kind of proof that there’s a squishy, slightly definitive delivery date for “done”. “Look,” we say, “based on our current velocity, we will finish the backlog around August!”. (If you’re reading this and it’s August, that’s August of next year.)

Even if we’re lucky enough to have the most Agile-minded customers who have bought into the whole Agile process, there’s one last step that has to happen. In my opinion, it is the most damning of all.

Bookkeeping

Think if you’ve ever seen the (or personally had) reactions to any of these types of requests:

• Ask a full-time, non-contractual developer to keep track of their time
• Ask a developer to write good technical documentation
• Ask a developer to follow a programming style guide without a linter/formatter
• Ask a developer to reconcile their estimated story points to actual development time

I’ve seen reactions to all of these and, more likely than not, it starts and ends with a tantrum. I’ve thrown some of those tantrums.

Software developers are so focused on “productivity” (or whatever) that the mere thought of asking them to inject a task into their workflow can send some of them into the longest arguments against the task with justification more complex than trying to explain P vs. NP to someone.^[3]

I think most software developers equate “bookkeeping” and “busy work”. In many cases, that may be true. With story points, it is not.

If you can’t set a standard baseline for story points, then story points are worthless.

If the team can’t understand that baseline, then story points are nearly worthless.

Let me posit something unorthodox: Reconciling what the team estimated and what actually happened is why team retrospectives exist. I assert that is unorthodox because most retros that I’ve attended in the last decade are sticky note driven meetings on some kind of anemic SWOT analysis board.

The part of the retro where the team discusses how to get better? That is the perfect time to do point reconciliation. It is a specific tactic with measurable outcomes that affect the team every iteration.

The Twos

For me, “The Twos” give me a way to help my feelings of uncertainty about estimation. I want to give good estimates. I want to be held accountable and succeed with my team for the customer.

Two hours is a silly estimate reserved for the most trivial changes. If you have to write a unit test, then you’ve generally exceeded two hours. If you need to review code you’ve never seen (or haven’t seen in a month), then you’ve generally exceeded two hours.

Two days is where most estimates should be. This means that the user stories must be expressed in a way that you can confidently give that “two day” estimate. You have to know the code that you’re going into. You have to see the solution in your mind because you’ve coded something like it recently (or have coded it a thousand times). This is the estimate for unambiguous things.

Two weeks is for anything that has a whiff of ambiguity. Ambiguity leads to questions and reviews and prototypes. Just give yourself two weeks to do it. Two weeks is about the best any average person can estimate without completely known tasks that have enumerated steps on how to achieve them. Otherwise, we will have to exercise the creativity of our craft. Boom. It’s now been two weeks.

Too long is the ∞ card in Planning Poker. This is just so you (or someone) can sit down with the customer and do some good ol’ “story slicing”. Ron Jeffries advises that if you can slice a story down until each of the stories each has a single acceptance test, then you have found the right size for the stories. You can generally get it into hours, days, or weeks at that point.

That’s “The Power Of Twos”! I hope you and your team can find it useful during your planning sessions.