Estimation is a potentially game-changing Agile practice that often gets overlooked by teams who are focused mainly on releasing new and more work to keep their stakeholders satisfied. However, consistently biting off more than you can chew leads to serious roadblocks and burnout that can harm team and stakeholder relationships in the long term.
This is where estimation can really help by supporting teams in determining their capacity and using it to negotiate workload and deadlines.
However, there has been an ongoing debate about the best approach to estimate your team's capacity – by hours or by effort. Traditional teams are more used to using a time scale, whereas Agile teams try to pin down the level of effort instead.
In this article, we will discuss both methods and why one might actually be better than the other.
Teams can’t become high-performing without a good understanding of their own capacity. If you’re aiming to provide a consistent flow of value to your customers or stakeholders, estimation is a key component of your planning process that you shouldn’t neglect.
Teams benefit from understanding how much work they can realistically complete in a certain timeframe as a way to make estimates more accurate. By understanding their average output, whether that’s in hours or effort, teams aim to avoid any frustration or burnout from having too much on their plate.
Accurate estimation isn’t just good for teams. Customers and stakeholders also want to know when they'll receive the value they've requested. Being able to provide a relative answer to the question "When will this be done?" helps set healthy expectations with the people you’re trying to serve.
There are various estimation techniques out there. Let’s explore the two most common ones so you can make an informed decision about which one will bring the most value to your team.
Time-based estimation is widely applied across traditional teams. The concept is focused on estimating how many hours a piece of work will take before even getting started. This approach is often used in traditional organizations that base their success on the quantity of deliverables produced in as few hours as possible.
However, the major issue with hourly estimates is that the team members’ experience, daily interruptions, dependencies, and regularly occurring surprises that add up to the workload aren’t taken into account.
For example, your team has to create a downloadable resource for a client. You estimate that it would take 20 hours to complete and you manage to do the first draft within this timeframe. However, it turns out that the resource requires an additional 10 hours of work based on the stakeholder’s feedback. As a result, your initial estimation turns out to be completely wrong.
In general, humans are notoriously bad at estimating how long something will take. Couple that with complex organizational systems and many dependencies, and you’ve got a recipe for guess-timates that, over time, start to drive the process in unrealistic directions.
The hourly estimation doesn’t take into account the important context surrounding the task and the people performing it but rather focuses on the output. This can lead to inaccurate estimates, and then delays, and upset stakeholders. That’s why estimating based on hours may not be your best option.
Effort estimation is the process of predicting how much effort will be required to complete a project’s deliverables. This approach allows teams to plan their capacity more realistically, so they can make commitments they can keep, generate value in the process, and maintain good relationships with their stakeholders.
Effort-based estimation aims to identify the average level of effort required to complete work as perceived by the specific team assigned to it. Meaning that the same work item, can have varying levels of effort depending on who is tasked to complete it.
This estimation technique is a collaborative bottom-up process that is owned by the team. Instead of a project manager taking the lead, teams gather together to determine how much effort will be required to complete tasks in their marketing backlog.
The question isn’t “how long will it take to complete this” but “how difficult is it for this group to complete if we behave cross-functionally”.
Agile teams typically use story points to estimate effort. Story points are a type of abstract value that considers the relative size and difficulty of a project or task (more on story points below).
Across the board, the most successful Agile teams estimate their work based on effort using story points. Unlike estimation by the hour, which rarely reflects reality, calculating the number of items or varying levels of difficulty that a team can tackle in a period of active work provides better accuracy.
For example, if we immediately assume that a team member has 8 hours of capacity each day, and could therefore complete a work item that takes 8 hours to complete, we would be encouraging the pace of work, but not necessarily its quality.
On the other hand, estimating how difficult something is, relative to other types of work, doesn’t focus on speed as a metric for success, but rather on quality of the solution.
Furthermore, understanding the difficulties helps teams plan accordingly and avoid potential major delays that can harm the flow and the relationship with stakeholders.
As teams realistically estimate their effort, they have a clear vision of their capacity and ability to say no to surprising projects that aren’t planned in advance.
Before moving on to learn several Agile estimation techniques, why don't you take a second to get the most recent State of Agile marketing report?
The transition from time-based to effort-based estimation can be tricky. Luckily, there are multiple Agile techniques like T-shirt sizes, Story Points, the Fibonacci sequence, and Planning Poker, that make effort-based estimation easier to weave into your existing process.
This is one of the most well-known Agile estimation techniques out there and also the most simple. It’s a great way to get an overall estimate of the relative effort level of the action items in the backlog.
To implement t-shirt sizing for effort estimation, the team attributes a t-shirt size to each of their backlog items to represent the complexity of each activity during their planning event.
The sizing hierarchy is borrowed from clothing – XS (extra small), S (small), M (medium), L (large), to XL (extra large). Each one shows how much effort is required to complete a task.
Simple, daily tasks that aren’t time-consuming and get done by one person in a few hours to a few days merit an XS, S, or M sizing while larger and more complex work that requires internal and external input over the course of a week or more of work is usually equivalent to L or XL.
For example, creating a social media post would be a size S in the t-shirt sizing scale while building a creative brief for a new campaign will be M, and budgeting for a new product or crafting a new strategy might deserve an L or XL, depending on the team’s familiarity of the work.
Agile teams use Story Points to estimate the amount of work, the complexity, and the risks associated with certain work items that have been prioritized highly in their backlog.
Assigning numerical values, instead of t-shirt sizes, to indicate the complexity of a piece of work is an abstract, relative way to also show the relationship between items in the current iteration.
For example, if a user story with a value of 8 is as difficult as a 5 and a 3 task put together, then the team can decide whether they want to start working on the most challenging work in their backlog or go for the quick wins instead (1s & 3s for example).
You can use Story Points estimation during backlog refinement or Sprint planning. For accurate estimates, it’s extremely important that the people who assign story points are the ones who will be doing the work, so they can assess their own skill level. A junior team member might assign an 8 to a new type of work they have no experience with. Whereas, for a senior team member, the same type of work will only be a 3 in difficulty level.
Instead of linear story point assignment, Agile teams estimate effort using numbers that have a bigger jump in between, like the Fibonacci Sequence, in which each number is the previous two added together. The Fibonacci Sequence is a set of progressively increasing numbers that are used to gauge how much effort will be needed to finish a task. Teams get together to discuss the upcoming Sprint and assign story points to each work item, selecting numbers from the Fibonacci Sequence.
The progressive structure of the Fibonacci scale makes it straightforward to distinguish between simple and complex activities, which supports teams in making informed decisions about their capacity.
No matter if the team completes the committed work or not, this can be a great opportunity for a realistic discussion about the capacity, what new learning was generated from the previous sprint commitment, and how estimation can be improved for the upcoming workload.
Planning Poker is a consensus-based effort estimating technique. Teams employ this gamified practice to estimate the difficulty of work activities as an average of every team member’s opinion. The estimates are often more accurate since they’re based on the input of the whole group.
Teams use planning poker cards that contain the values from the Fibonacci Sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) to vote on the level of difficulty of a user story. Members discuss the specifics, then each of them selects a card to represent their estimate. All cards are revealed at the same time. All members should agree on the size of the task before moving forward and voting on the effort level of the next piece of work.
However, if there are different opinions on the effort required and the value of the cards isn’t the same, the team can discuss their estimates further and gain a stronger shared understanding about the requirements of the work.
The popularity of time-based estimation is dwindling in the face of effort-based estimation as a technique.
Effort estimation allows teams to have a shared vision and understanding of what is required of them and are able to keep realistic commitments to their stakeholders in the short and long term.
By understanding effort instead of trying to guess-timate time, Agile teams are better equipped to organize their capacity so they can make reasonable promises, avoid overburden, provide frequent value, and uphold positive stakeholder connections.
The first step is always the hardest. That's why we've built a library of content based on years of working with Agile marketing teams, and broken it down into 4 microlearning paths for different contexts:
Each of them contains 10 bite-sized lessons, 20 short engaging videos, and 10+ downloadable resources that can boost your Agile knowledge in minutes even during the busiest days.
Before you move on, don't forget to get the most recent State of Agile Marketing Report.