You want to create value as fast as possible. But how do you calculate “value”? And what is considered “fast”? If you don’t know, let’s estimate.
Agile is all about creating value in the shortest possible time frame.
It is key to ship early and often, but not at any cost. Every Agile team should estimate the value of the work as well as estimate the required effort to complete it. Only when you know both the projected effort and projected value added will you be able to compare listed items and pick those with the best Value to Cost ratio.
In our series describing the 6 fundamental differences between the nature of Agile Marketing and Agile Development we’ll now look at how to estimate.
What should you estimate? Effort? Value? Maybe even risk?
Most scrum teams estimate the effort required to get something done. Popular measurement units are story points or T-shirt sizes. Coming up with estimates is a team exercise. Estimation meetings can reveal different team member perspectives of the current situation, generate interesting insights and already starts building some form of commitment from the team.
The estimates on value contribution are normally less of a team effort. They are done by the Product Owner via prioritizing the backlog.
There are multiple ways of doing estimation and different measurement units to use. Let’s start with listing popular methods for estimating effort, then consider value and end with something which is not that common yet in agile… estimating risk.
T-shirt sizes: team members estimate relative efforts of the items on the list by giving it a Small, Medium, Large or Extra Large label. The good thing is that it is a very easy and quick way to cluster items and put them in a sequence from “a little” to “a lot”. The bad thing is that T-Shirt sizes are not additive; 2 Large items do not equal 1 Xtra-Large. Different team members are likely to have different ideas on what the agreed upon estimation actually says. T-shirt size estimation might be a good way to get used to doing estimations, but other methods are more accurate.
Story Points: Story points are usually not directly linked to hours or days, but are relative. E.g. something with 2 story points only takes half the time to develop as something that has 4 story points. How many hours “half the time” is, is unclear.
Story points use an exponential scale. The higher the estimation, the faster the absolute amount of story points increases. Different development teams can use different volumes of story points, which makes it hard to compare between teams. The advantage of Story Points is that estimations of Sprint teams themselves become more accurate in terms of which functionality they think can be delivered in a certain timeframe.
Estimating the story points can be a ritual in itself. Playing “Planning Poker”, members of the group make estimates by placing numbered cards face-down on the table. Members won’t be able to see others’ estimations before they have to make their own. The cards are then revealed, and the estimates are discussed.
MoSCoW: The MoSCoW method is a prioritization technique used in management. The acronym stands for Must Have, Should Have, Could Have and Won’t have. With MoSCoW you can prioritize the items on your requirements list and pick the ones that deliver the greatest and most immediate business benefits. Start with the M’s, almost certainly continue with the S’s and if time allows continue with the C’s. In terms of dynamics you could say the MoSCoW is the Value equivalent of the T-Shirt size estimations for effort. It is easy to use, but limited in its accuracy due to its non-additive character.
Impact/Effort Matrix: In this matrix the items are mapped based on two factors: the potential (business) impact and the effort required to implement. If, for every single item, you divide impact by effort then you can create a list sorted by value added.
Confidence level: Occasionally you encounter a team that works with a “confidence level”. The confidence level is a predictor of sprint success. It works like this; on a scale from 1 to 5 the team members can express how confident they are about being able to deliver the work within the upcoming sprint. If the average confidence score is lower than 3, it means there are too many uncertainties. It can be a knowledge gap, or the chunk of work just might be too big. If the confidence is too low, the team has to take a step back and break up the work into smaller pieces. If that does not results in a higher confidence level, the problem lies not in size but in the knowledge required. There may be a sizeable chunk of hard to acquire expertise missing from the team. If so, add someone with the right experience to your team or adjust your goal altogether.
So, how does this all relate to Agile marketing?
Many marketing teams are used to estimating effort in days or hours. Some Agile marketing teams work with T-Shirt sizes or story points, but generally speaking using days as the measurement unit does not seem to be as big of a problem as in it is for Agile Development. On the effort front, the estimation seems to be under control.
Where it becomes interesting is estimating the value added of marketing activities. A couple of blogs ago we introduced the Definition-of-Success, to be used in addition to the Definition-of-Done. The reason is that marketers do not only need to deliver items from a list, they need to achieve “success”. Normally that success is measured in change of customer behavior, brand awareness, revenue, share of wallet, clicks, views etc.
Introduce the Poker game to estimate Marketing Success
Some Agile Marketers say that “marketing content” is the core product of a marketing team. If that is the case then using the Definition-of-Done is sufficient.You’ve got your content, on to the next item. The Poker game is perfect to estimate effort on content creation.
However, if you see “change of customer behavior” as the core product of a marketing team, then this change needs to be estimated. A Definition-of-Done is not good enough. You want to know which results can be expected from getting things done. You’ll need to have a Definition-of-Success.
Discussing with a great number of Agile marketers we realized the power of introducing the Poker game principle to estimate the success of marketing activities. It would make agile marketing more value focused instead of task driven.
Thus, the marketing estimation method to go for is creating an impact/effort ratio where the impact score takes in to account risk or uncertainty. Effort can quite easily be estimated in absolute, additive terms, like days or weeks. Impact, the degree of commercial success the product is likely to achieve, can be estimated using the Definition of Success. To alleviate market uncertainty as much as possible, get a variety of marketers to estimate the expected success. If the confidence score for success is below 3, lower your Definition of Success. If the estimated success is still higher than the effort required, go right ahead!
- In development: the more demanding a User Story and the more complex a product, the more uncertainty about the workload. It will then be more difficult to do a proper estimation. The Poker game principle has been introduced to more easily estimate efforts. Value added is estimated by the product owner.
- In marketing: marketers traditionally estimate in days/hours and budgets. There is usually much less complexity-induced uncertainty in marketing than in product development. Therefore effort estimations tend to be pretty accurate. Days and budgets can be easily compared between teams. The estimation on the value added of marketing teams is a more difficult nut to crack. Linking the definition of Success to the Poker game principle might be an interesting option to explore.
So go ahead. Take a chance yourself. Or rather, don’t just take a chance, estimate! Using this estimation method is minimal effort, maximum impact. The easiest estimation of all.
This is article #6 from the series “6 Fundamental Differences Between Agile Development and Agile Marketing”.
There are some fundamental differences between how software development teams are run and how marketing teams are managed. As a result, not all agile software development routines can simply be copy & pasted from Software to Marketing and remain relevant. In some areas there is a match made in heaven, in some other areas there will never be a match. And in yet other areas it needs tweaking to become useful for marketing too.
A special thanks goes out to Gidion Peters from Scrumcompany.nl. His down-to-earth and practical comments helped us to sharpen our Agile Marketing thoughts.
Read other articles from the series here