Use story points or size to measure the effort of tasks
What is Agile Effort Estimation?
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 differentagile estimation techniquesteam members may use for effort estimation. Among them areSprint Poker– sometimes known asPlanning Poker–, where teams estimate effort using a deck of poker cards with values assigned to them. Or teams may estimate user stories informally during theirbacklog refinement meetings.
Agileteams usually estimate effort using ametriccalledstory points.Story pointsare an abstract value that takes into account the relative complexity and size of a task.
Teams tend not to estimate based onperson hours, but instead useStory points– a concept inherited fromExtreme Programming (XP).Story pointsare not a measure of how long a thing will take to complete.
Withineffort estimationthere are a varietystory pointscales 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 likeSprint Pokermakes 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.
How does Effort Estimation work?
Estimated Effortputs 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 largeragileprojectby 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. Thenstakeholdersare unhappy and thebackloggrows.
Estimating by effort is more abstract, but it also lets you prioritize and plan better.
Using Estimation Scales
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 – orstory point valueas 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 likeT-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.
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.
Estimating Effort with Parabol
Use ourSprint Poker toolto start accurately estimating stories in no-time.
Simplystart 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 fromagileworkflow 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 effortandvalue, you can do that with theWeighted Shortest Job Firstsizing method. Learn more about that here.
When you’re done sizing, you can send your stories back into yourproject managementtool 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.
