Estimated effort is a practice in agile software development where teams estimate the relative size of a task or product backlog item based on how much effort it will take to complete it. The practice is popular in agile software development and among software engineering teams.
There are many different agile estimation techniques team members may use for effort estimation. Among them are Sprint Poker – sometimes known as Planning Poker –, where teams estimate effort using a deck of poker cards with values assigned to them. Or teams may estimate user stories informally during their backlog refinement meetings.
Agile teams usually estimate effort using a metric called story points. Story points are an abstract value that takes into account the relative complexity and size of a task.
Teams tend not to estimate based on person hours, but instead use Story points – a concept inherited from Extreme Programming (XP). Story points are not a measure of how long a thing will take to complete.
Within effort estimation there are a variety story point scales teams like to use. These include:
Effort estimation is a collaborative and bottom-up process led by the scrum or agile team itself, rather than by a project manager, for example. Teams get together to create effort estimates for user stories or tasks in their product backlog.
Having an estimation process helps agile teams plan their work better and decide how many user stories or tasks they can expect to complete in their next development sprint. The number of tasks a team can complete is often referred to as sprint velocity.
Using a methodology like Sprint Poker makes the estimation process fun and helps teams get on the same page about the total effort required to complete a given task. As teams estimate more and more together they are better able to estimate using story points because they have a defined baseline from working on similar projects in the past.
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 a feature or larger agile project 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.