Learn to apply Agile Methods to Marketing in order to get more done, adapt to change and see immediate measurable results in Agile marketing training from ASPE-ROI.
Last time, I talked about how some Agile Marketing teams use Scrum but don’t use User Stories. And, as with other symptoms of Scrumbut, how that can come about for both good and bad reasons. Which leads us to our next symptom:
“We use Scrum, but we don’t do relative sizing.”
If you went through any formal scrum training, you were probably exposed to this relatively awkward concept – pun totally intended. In a nutshell, relative sizing systems simply allow you to say this is bigger/smaller than that. That’s why is called “relative” sizing – you’re not holding something up to an absolute scale to determine how large or small it is. And there are several “styles” of relative sizing, the most commonly used being:
- Modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
- Shirt sizes: S, M, L, XL, XXL
- Dogs: various breeds from Chihuahua to Great Dane
My favorite is the modified Fibonacci (Fib for short). But before digging into why you should use it, let’s take a quick look at what people are doing instead of relative sizing:
- Rough estimates in hours and/or days
Agh! Run! Once you start talking in terms of hours and days it’s hard to keep “rough” in perspective. People have an ingrained habit of trying to be precise and accurate when they’re discussing time estimates. Before you know it, someone starts creating a Gantt chart to make sure they’re coming up with an accurate “rough” estimate. Actually, they’ll wind up creating a precise but very inaccurate estimate in that case, but I digress.
Unfortunately, it’s also reinforced by the people who ask for the estimates. I remember a GM asking me how long it would take to put together an analysis and proposal for a new product opportunity, and I told him about 3 to 4 weeks. And without missing a beat, he asked me what it would take to make sure it took 3 instead of 4. Ugh.
Statistically, estimating something and winding up within + or – 10% sounds pretty good in many applications. However, when it comes to time estimates, taking 10% longer is NOT the same as taking 10% less time than estimated – you get hammered a lot harder for missing a deadline than for beating it. Even with the latter, if you’re always finishing within your estimates, you eventually get accused of intentionally sandbagging and are pressured to lower your future estimates.
Relative sizing breaks these habits by forcing you to deal with units of measure that can’t be readily compared with actual time. Relative sizes encompass not only time but also risk, complexity, and general uncertainty. When you decide to actually do the work, e.g. in your sprint planning meeting, you will break down items in tasks with actual hours – but at least then we’re waiting until the last responsible moment and we’re having the actual team members come up with estimated time of the actual tasks involved. Doing a time-based estimate before this point is just asking for trouble.
So how does relative estimation solve these problems? If I ask a given marketing team to say whether campaign A or campaign B is more work than the other, we’ll probably have a short discussion, then they’ll decide. Then if I ask that same team later to estimate whether a new campaign, called ingeniously enough campaign C, is more work than A or B, we’ll have some discussion and they’ll decide. And I could keep asking the same team to give me a relative ranking of different campaigns until we have agreement that, roughly speaking, these over here are the smallest, those over there are the largest, and we have a couple groups of campaigns that we’ve ordered between those two extremes.
Now if I start having that team actually implement those campaigns during sprints, we’ll start to see how many of the relatively largest campaigns we can get done in a sprint, how many of the relatively smallest, etc. So over the course of a few sprints, just by using a consistent relative sizing system combined with the actual productivity of the marketing team, I can ask them to give me a relative size of any new campaign, and after a short discussion, get a rough estimate of how long it would take to get done.
Wait a minute? Did I just say “how long” as in “actual time” kind of long? Yes. Because sprints last a fixed period of time, your relative sizing and productivity data will let you determine roughly how many sprints-worth of actual time a bunch of stuff will take. And if you try to get more precise than that, you’re losing sight of the “rough” part of rough estimates.
When it comes to specific relative sizing systems, I prefer Fib. Because it’s numeric, you can easily do some math with your rough estimates. And if that sounds dangerously precise, the way the Fib numbers are spread out has a magical way of building in just the right amount of wiggle room. There are specific tips and tricks to using it well, and I like to cover those in my Agile Marketing class – you can get the same tips from most Scrum Master Certification classes too.
OK, so maybe it’s clear how relative sizing gets your brain out of the “must. be. more. precise.” mode. But how does it get the people who asked for the estimates to get out of that mode too? It’s simple – if I told that GM that the analysis and proposal would be a 13, or a Medium sized shirt, or a German Shepard, do you think his brain would have immediately translated those answers into due dates? It shifts the conversation back to one of sprints – which sprint will you get this done in? And again, that’s as precise as we want to be in that situation.
If this explanation didn’t quite click, don’t worry – relative sizing and estimation isn’t the most intuitive thing to pick up. It’s much easier to learn it through some live exercises and discussion. Did I mention I cover it in my class? Hopefully this post was relatively helpful. At least as helpful as a Labrador Retriever anyway.
Well that’s the end of my posts on Scrumbut – for now. I’m sure I’ll encounter more examples of “we do scrum, but…” and this topic will be resurrected. In the meantime, I hope this topic has helped you to use best-practices that didn’t click the first time around. If it did, I’d love to hear about it!