The engine of any Agile team is their prioritized backlog. That's why, rightly so, many teams will start their Agile journey by putting together a team-level backlog to reflect their workload and make it easier for them to prioritize as a group.
But, for backlogs to work their hardest, Agile trainers and coaches recommend that every backlog be as DEEP as possible. DEEP is an acronym used to describe some of the most important traits of a healthy team backlog.
It stands for:
Detailed, meaning it contains the information the team needs to get started on the work items that get prioritized up
Emergent, meaning it reflects the current state of affairs and reacts to new information coming into the team
Estimated, meaning the team has a shared understanding of the capacity it will take to complete the work in the backlog (ex. small items are differentiated from big)
Prioritized, meaning the backlog is not just a random to-do list, instead, the order of the work items in the backlog reflect priorities from the customer’s perspective
In order for a backlog to be truly deep, all of these elements need to come together. Unfortunately, most teams focus on prioritization and detail, while estimation remain an afterthought.
With estimated work in their backlogs, Agile teams can plan their capacity more accurately, avoid disappointing stakeholders by making realistic commitments and, ultimately, become a reliable generator of value-adding deliverables to customers.
Part of the reason for estimation getting overlooked is likely that Agile estimation looks different than the estimation that we might be used to in traditional marketing. It has a different focus, which sometimes make it feel more intimidating.
Let's demystify Agile estimation to make it easier to integrate into our process. Here's how to get started with estimating your work, itimidation-free.
Traditional Estimation vs Agile Estimation
Many new Agile teams put off estimating their work in the backlog because Agile estimation is, put simply, foreign territory.
In a traditional marketing team, estimation is often based on time because stakeholders are always asking the question, “When will it be done?”
It’s only natural that service-oriented marketing teams will aim to please by providing a time-based estimate about their work items.
However, estimating based on time is also one of the most inaccurate forms of estimation out there. Not only are human beings notoriously bad at determining how long something will take, they also rarely take into account the interruptions, the dependencies, and the other ongoing work that will factor into the estimation.
For greater accuracy and as a tool for making informed decisions around capacity, Agile teams estimate their work based on effort instead.
When the question becomes “how difficult is this to complete” versus “how long will this take to complete," we're able to make more accurate estimates about what we can feasibly deliver as a group and when.
Methods of Estimation
If you’re not sure how to shift from time-based to effort-based estimation, there are a number of different methods for estimating effort that are all excellent entry points into this vital Agile practice.
T-Shirt Sizes
One of the most common (and most well-known) estimation techniques that we’ve seen work wonders for new Agile teams is t-shirt sizing. It's used to generate a high-level estimate of the relative effort level of work items against each other in the backlog.
At a short-term planning event, such as a biweekly sprint planning, the team will assign a t-shirt size to each of their prioritized work items to reflect the level of difficulty of each one. In a single sprint backlog we might encounter:
3 X Small (e.g. Generating a report, sending an email)
2 X Medium (e.g. Building a creative brief for a new campaign)
1 X Large (e.g. Defining a budget for a new product)
Generally, if a piece of work is complex, time-consuming, and requires input from several different parties, even sometimes external to the team, it merits either an L or XL sizing.
More simple, familiar work that won’t take too much time and can be completed by someone working autonomously will merit an XS, S, or M sizing.
To avoid the overhead that can result in tracking work items that are too insignificant, some teams opt out of implementing the XS size.
Similarly, to avoid entire campaigns being tracked as a single, vague work item on the board, many Agile teams implementing this estimation technique steer clear of assigning XL sizing.
Fruit, Dogs, etc.
When you’ve met as wide a variety of creative teams as we have in our day, you’ve probably encountered some interesting interpretations of Agile estimation.
Two standout techniques that work similarly to T-shirt sizing, but introduce an element of fun into estimation to make it less intimidating as a practice are sizing with a fruit scale and a….dog scale!
As out-of-the-box as these methods may seem, there's certainly a method to the madness.
In no time, you team will be participating in meaningful conversations like:
“Is this a Saint Bernard task, truly? I had no idea.”
“Yes, it’s a Saint Bernard because we need to loop in Sales and Product over the course of the sprint and I also need Sarah to help me with the visuals.”
“Ok, it’s helpful to anticipate this dependency. Also, Sarah is out this week, we may need to break this work down into a Husky and an Akita, so you can progress without Sarah in the next two weeks.”
The magic of estimation comes from developing a shared understanding of the effort required to complete a work item that hasn’t been started yet and make realistic commitments to our teammates and business partners.
Whether you achieve that using a scale based on dogs, fruit, or t-shirt sizes is up to you and your team.
Fibonacci Sequence
More mature Agile teams play a numbers game when it comes to estimation. Often, they implement a sizing technique based on the Fibonacci Sequence of numbers.
The reason we often see the Fibonacci Sequence (ex. 1, 2, 3, 5, 8, 13…) being used in Agile estimation instead of a linear sequence of numbers (ex. 1, 2, 3, 4, 5…) is the big jump between the numbers as you go down the line. With Fibonacci numbers, there is a more meaningful difference between the numbers that results in greater clarity when we try to compare them relative to one another.
For example, the difference between a 7 and an 8 work item based on effort, seems abstract and insignificant. But, in comparing Fibonacci numbers, we have greater confidence that a size 8 piece of work is 8 times harder to complete than a size 1 piece of work. A size 8 work item might also be considered to be as difficult as a 3 and 5 task put together.
While using numbers might seem like we’re introducing an extra level of complexity into estimation, it also has its perks.
If we use numbers, we can sum them up for a better understanding of our capacity. For example, if a team commits to the following:
3 X size 13 work items
2 X size 8 work items
5 X size 2 work items
3 X size 1 work items
We can total all of the estimates together and calculate that the team’s prospected velocity is 68 points of effort.
Whether the team manages to complete everything they committed to, or leaves some work unfinished during the sprint, can open up a whole variety of new conversations about capacity and reasonable workload for the next period of active work.
Planning Poker: Agreeing On Team Estimates
What happens when people on the team don’t agree on the proposed effort level for a work item in the backlog?
It’s certainly a common situation, especially when we are aiming to come to a consensus about relative effort on the team level.
For someone junior on the topic, Work Item X can seem extremely complex. For someone senior, as simple as they come.
Planning poker is a common technique used to arrive at an average effort level for each work item our collaborative, cross-functional Agile team will undertake in the upcoming sprint.
During this gamified activity to support estimation, members of the team make estimates about prioritized work items and share them by playing numbered cards face-down on the table, instead of speaking them aloud.
If team members agree, the assignment size is clear. If there are differences, these can be discussed for greater clarity and team members can make a case for their votes.
If consensus can’t be reached, an average can be assigned.
Getting Started With Estimation in Your Team
Contrary to common misconceptions about estimation, estimation techniques are not difficult to implement and they’re not geared towards pushing working groups to the absolute limits of their capacity.
Instead, estimating the effort level required to complete work items in the backlog provides incredible insights about how much the team can feasibly complete in a given timeframe and influences how they plan their capacity.
In turn, understanding team capacity is the most crucial step towards becoming a team that is predictable and consistent in their value delivery to customers, in other words, a team stakeholders can trust to get the job done.
Improve your Marketing Ops every week
Subscribe to our blog to get insights sent directly to your inbox.
