The Top Floor Flat

This is Part II of Challenges in Setting Up an Agile Marketing Team. Part I is available here.

Challenge: Measuring and assigning points to marketing stories

Agile is a great method for quantitatively measuring productivity because each story is assigned a point value. The sum of points from all stories completed during a sprint defines the team’s velocity. This velocity should be fairly consistent week on week and any sprint plans for the future shouldn’t include stories with a point value higher than the current velocity. Within a development environment, when, generally speaking, product developments are all created within the same framework (a programming language) with varying levels of complexity, the point values are relatively easy to define – a more complex project, requiring a greater knowledge of the coding language, is worth more points.

On the marketing side, however, assigning point to stories has been a real challenge. There is no consistent measurement of complexity across the very different types of projects we undertake – for example is designing a lead flow process for lead nurturing more or less complex than generating a detailed report analysing dead leads over the last six months? And if we can’t consistently evaluate complexity, should we use time to indicate point value – so should a very simple, repetitive task that takes an entire afternoon be worth more points than a task that only takes half an hour but requires a significant level of expertise? Should points indicate seniority – tasks that require executive sign off getting a higher value than those that do not?

Where We Are Now:

This particular issue hasn’t entirely been resolved. We’ve tried a number of different ways of measuring the point value of tasks but have resorted to ‘gut feel.’ We assign points as a team, during our sprint plan, so there is a check and balance but it’s not a particularly scientific process. This has been reflected in a somewhat inconsistent velocity – although we’re in the same ballpark week on week, our velocity doesn’t have the fixed value we’d like to see. Generally points are based on a combination of the perceived complexity of the task, the amount of time it will take and whether or not other resources are required from outside our department. Hopefully this process will become clearer.

As a side point, we used the same point values as our development team – 1, 2 or 3 points as the only options. Given the different variables we need to take into account and the inconsistency of measurement, we might find it easier to get a lock on our velocity with another scoring system.

Other Challenges:

A couple of other challenges that we considered before starting with Agile:

–        Abundance of ‘chores.’
Chores are stories that don’t deliver any real value but must be completed. Some examples are following up with the winner of a competition, cleaning email lists or unfollowing irrelevant accounts on Twitter. Chores in our sprint plan give the appearance of productivity without any value-add to the department, and makes it more difficult to accurately measure our velocity (chores don’t get any points). We tend to have a lot of these within marketing and are working to tie these in as tasks related to proper stories, rather than just stand alone stories without value.

–        Lack of resources and skills for partner work
Many Agile teams recommend having paired teams of workers complete stories together. While our challenge is based more on the siloed skills sets within our team, our small team size and general need for speed has deterred partner pairing as well. However, we’re lucky enough to have some fantastic interns working on the marketing team and although they are not generally part of the sprint plans or responsible for stories, their support helps us recognise some of the value of pair work.

–        Reliance on other company departments
Within the development team, much of their work is self-contained however in many cases, our marketing team requires support from other departments to complete a story – whether that’s a product release from dev or testimonials from support. Reliance on other departments makes planning stories incredibly difficult because if we don’t get what we need from the other parts of the company, the story can’t be completed. We haven’t found a great solution for this one yet, although we have tried to write fewer stories that require outside resources and if one is required, create a chore to request the resource, then a story only once we’ve received what we need.

So, as you can tell, numerous challenges although it’s been an important process to think about these because they affect the team’s output regardless of the methodology we’re using. Agile has helped to highlight some of the ways we can improve and given us a framework for doing so.

Next post will be about how we prioritise work, define projects and write stories.