Story Points or Hours?

Sprint Backlog

Photo credit: CannedTuna

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 Agile Marketing? Is there anything about the nature of marketing 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.

If anyone out there has experience using hours or story points or t-shirt sizes for Agile Marketing, please tell us about your experiences in the comments.

Enhanced by Zemanta

Comments

  1. We’ve been having this same debate among our team.

    I think for many story points are too amorphous — what’s a 1 point story? What’s our baseline?

    On the other end using hours brings in the experience problem. There can be a lot of disagreement about what a 1 hour project looks like too.

    I’m going to try t-shirt sizes as a middle ground and I’ll let you know how it goes.

  2. We’ve been having this same debate among our team.

    I think for many story points are too amorphous — what’s a 1 point story? What’s our baseline?

    On the other end using hours brings in the experience problem. There can be a lot of disagreement about what a 1 hour project looks like too.

    I’m going to try t-shirt sizes as a middle ground and I’ll let you know how it goes.

  3. Here is a story publicized by theserverside.com this week:

    https://www.industriallogic.com/blog/stop-using-story-points/

    Also see this video:
    https://youtu.be/XU0llRltyFM

    I generally prefer hours, with some caveats:
    1 – there is no such thing as a 1 hour task
    2 – tasks need to include unit testing (ideally Test First) + documentation (ideally Document First)
    3 – use blocks of hours – 2, 4, 8, 16, 32, 64?, too big to estimate break down to smaller tasks
    4 – if a task is not complete in the given hours, discard the work and re-estimate, or check in the partial work, and add a new task.

  4. Here is a story publicized by theserverside.com this week:

    https://www.industriallogic.com/blog/stop-using-story-points/

    Also see this video:
    https://youtu.be/XU0llRltyFM

    I generally prefer hours, with some caveats:
    1 – there is no such thing as a 1 hour task
    2 – tasks need to include unit testing (ideally Test First) + documentation (ideally Document First)
    3 – use blocks of hours – 2, 4, 8, 16, 32, 64?, too big to estimate break down to smaller tasks
    4 – if a task is not complete in the given hours, discard the work and re-estimate, or check in the partial work, and add a new task.

  5. Within our team, I prefer to use hours but it can really be a problem with team members having different set of skills and experience, making a 2hrs task for somebody, an 8 hour task for somebody else as you mention in your blog post.

    For this reason a sprint planning will go this way:
    – We prioritize tasks based on Product Owner feedback and our own judgement
    – Each member of the team takes ownership of the tasks he wants to work on
    – Team members estimates the time necessary to achieve their own tasks with feedback from the rest of the team. Some adjustments might be done.
    – Remaining tasks get divided depending on each member’s workload
    – We use points but each point is worth 2hrs. We work on 40 points per sprint (2-week sprints) per person.

    After each sprints and thanks to the sprint retrospective, team members become better at estimating the time necessary to achieve a certain task.

  6. Within our team, I prefer to use hours but it can really be a problem with team members having different set of skills and experience, making a 2hrs task for somebody, an 8 hour task for somebody else as you mention in your blog post.

    For this reason a sprint planning will go this way:
    – We prioritize tasks based on Product Owner feedback and our own judgement
    – Each member of the team takes ownership of the tasks he wants to work on
    – Team members estimates the time necessary to achieve their own tasks with feedback from the rest of the team. Some adjustments might be done.
    – Remaining tasks get divided depending on each member’s workload
    – We use points but each point is worth 2hrs. We work on 40 points per sprint (2-week sprints) per person.

    After each sprints and thanks to the sprint retrospective, team members become better at estimating the time necessary to achieve a certain task.

Trackbacks

  1. […] provides several tools to mitigate Parkinson’s Law. First of all, time estimates (whether in story points or hours), are not dictated by the boss and generally not by any single person, but rather by the team. […]

  2. […] provides several tools to mitigate Parkinson’s Law. First of all, time estimates (whether in story points or hours), are not dictated by the boss and generally not by any single person, but rather by the team. […]

  3. […] 87. Speed: Counting the number of story points related to the complexity of the tasks and projects a team gets through in a work cycle or period can enable you to measure speed, productivity and improvement. (Jim Ewel, Agile Marketing) […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.