Storypoints vs Hours

Most Agile Marketing teams use either Scrum or Kanban methods to manage their work. If you use Scrum, you’ll need to use either story points or hours to limit how much work you take on in any given sprint. Which is best for Agile Marketing?

For Agile Developers, story points versus hours has been a long running debate. Feelings seem to run high on both sides, with the father of scrum, Jeff Sutherland, coming down squarely on the side of story points, while others like Mike Cohn of Mountain Goat Software feel that story points are inappropriate for the short-term nature of a Sprint.

What about for us? Is there anything about the nature of our tasks that makes story points or hours more appropriate? While the short answer is that you can use either, I think most teams will be happier and more productive using Story Points or one of its variants (t-shirt sizes for example).

First, what is a Story Point? Story Points arose from the observation that it’s very difficult to estimate tasks in absolute units like hours when the task is not yet well-defined, and  estimation itself takes time, time that might be better used to produce results. Estimating tasks in hours or days also fosters a false sense of precision.

Story points are relative: a task estimated at 2 story points takes roughly twice the time and effort of a 1 story point task. This holds true, even if the experience levels and productivity of different team members varies widely. For example, let’s say a very experience marketer can get a 4 story point task done in 4 hours, where it might take a less experienced person 16 hours. On a relative basis, you can compare tasks, and a team composed of both experienced and inexperienced marketers would have a certain velocity, i.e., number of story points completed per unit of time.

How can you get started with Story Points? Many people ask: “how many hours in a story point?” Is each point worth 2 hours? 4 hours? This is the wrong way to think about it. For one thing, time isn’t the only factor in estimating story points – difficulty and uncertainty play a role as well. Something that is less well understood, and something that is more complex, should be assigned more story points, even though some of these tasks might actually take less time than expected. Others will take more time.

I suggest starting by taking a known task, well understood by the entire team, that is average or typical.  Assign that task either the t-shirt size medium or 4 story points. Then group other tasks in piles relative to the typical task – is the task similar in time, complexity and understanding? It goes in the same pile. Is it half the effort? It goes in the 2 story point or small pile. Twice the effort? 8 story points or Large. Don’t spend too much time on each one, just get them roughly sorted. Over time, you’ll get a better sense of which tasks belong in which buckets. The point isn’t to get an exactly accurate estimate (an unrealistic goal), but to get to a rough understanding so that the team can commit to the work.

Over the first 3-4 sprints, the team will generally improve their velocity, or the number of story points that they can complete in a given period. Then the velocity will tend to either stabilize or will improve gradually over time.

One last point – the other reason that I like Story Points is that they are a unit of production, and the team should focus on production, as well as knowing their velocity of production. After all, it isn’t the hours we put in that count, it’s the work we produce.