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.
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.
Sounds like a familiar debate. Good luck and let me know how things work out.
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.
Sounds like a familiar debate. Good luck and let me know how things work out.
Pingback: Agile Marketing and Three Laws of Human Interaction
Pingback: Agile Marketing and Three Laws of Human Interaction
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.
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.
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.
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.
Pingback: 101 Things to Know Before You Go Agile Marketing | Simple