From scheduling a food delivery to planning your morning around a dental appointment, accurate estimates about how long something will take are helpful.
But that’s only when the variables are relatively consistent. When working on a team, be it software development or product marketing, sizing by time alone can lead to missed deadlines and increased backlogs.
Sometimes a team hits a roadblock – buggy code, unavailable resources, complicated integrations – and the initial time-based estimate goes out the window.
That’s why using the Estimated Effort method is a solid approach for agile teams.
It prioritizes the amount of work (or the effort) first.
Estimated Effort puts the emphasis on the effort required to complete a given task, rather than the anticipated amount of time. So your team will each vote on how much effort a task involves according to your chosen estimation scale.
Think about putting a route into your maps app at the start of a journey. It might default to assume you’re using a car, and it gives you an estimated time of arrival. But you can switch to bike directions or even walking directions, this quite literally changes the effort it takes to get to your destination.
The distance for the trip is the same, but the time changes dramatically as you swap between the three. The amount of work has a huge impact on how long it can take, which is why it’s beneficial to start with that first.
Many teams estimate by time (it’s the natural thing to do), but be warned! They’ll often meticulously plan to complete something according to the car’s projected time, and end up finishing a project as if they rode a bicycle over the finish line. Then stakeholders are unhappy and the backlog grows.
Estimating by effort is more abstract, but it also lets you prioritize and plan better.
The bike and car from above can be thought of as scale items when estimating by effort – the bike is more effort than the car in this case.
Using a scale when estimating effort helps categorize effort without getting too granular. Think of each scale item – or story point value as they’re more commonly referred to – as an abstract and flexible unit of measurement.
Typically that unit is a combination of the effort, complexity and uncertainty in any given task. Some people assign numbers to their story points, others use abstract items like T-Shirt sizes. The abstraction is easier to grasp with a sizing scale that everyone on your team can agree on.
Let’s use T-Shirt sizes as an example:
We’ll use a range of extra-small to extra-large. Your team will gauge the effort of each story by shirt size. Extra-small represents the least amount of effort and extra-large represents the most effort. There’s no universal work size equivalent to these shirt sizes, and that’s kind of the point. Your team will need to have some discussion about what constitutes a small, medium, large or extra-large effort.
If someone were to give you a single t-shirt, it might be hard to gauge the size just by looking at it in isolation, but put it next to another t-shirt, and it’s easier to recognize. Use the relativity of your scale sizes to your advantage. Once you’ve worked out what’s a small t-shirt task, it’s easier to accurately size the others.
Use our Sprint Poker tool to start accurately estimating stories in no-time.
Simply start a Sprint Poker meeting, then choose Estimated Effort and your preferred sizing scale.
From there you’ll kick off the meeting with an optional icebreaker, and then get on to estimating. You can import stories from agile workflow tools such as Jira to speed up the estimating process. As each story comes through, participants vote on the size in secret. When everyone is done, the facilitator will reveal the votes and the team can quickly discuss any discrepancies and form a consensus.
If you want to estimate effort and value, you can do that with the Weighted Shortest Job First sizing method. Learn more about that here.
When you’re done sizing, you can send your stories back into your project management tool and grab a full report on your Sprint Poker meeting. In time you’ll be able to chart your team’s sizing accuracy and resource allocation across sprints.