Break Down Agile User Stories into Tasks and Estimate Level of Effort (2024)

The Agile framework has brought about a strong cultural shift in the software development world, away from extensive planning and towards iterative and lean execution. One thing that has not changed, however, is the fact that everyone still expects estimations of when software features will be delivered, and how long a project will take to complete. Task planning and estimations are hard, perhaps enough to consider them as both science and art. It can feel like an intimidating, daunting task for developers and product owners.

That being said, when it comes to breaking down Agile user stories into tasks and estimating their level of effort, there is good enough "science", or at least proven practices that you can rely on. In this guide, you will learn what they are.

One thing that needs to be established right away is the fact that this is a team effort. While the product owner is responsible for prioritizing the backlog and capturing requirements from the business and the users, the developers are really the ones best positioned to understand what in terms of technical capabilities must be developed, as well as the level of effort entailed.

There are a few important things to consider when breaking down user stories into tasks:

• Keep tasks small, but not too small. As a rule of thumb, a task should be something that can be done within a single day, but not in a few minutes' time either.
• Keep tasks very precise in scope. Don't create tasks with such vague statements as "Coding" or "Implementation" thinking that anyone can just refer to the parent user story for details. Write something more meaningful that also makes the scope very clear. For example: "Develop the login class."
• Use the user story's acceptance criteria as a starting point, and its definition of done as a checklist. The acceptance criteria will help you determine what features need to be implemented, and the definition of done is a checklist for all user stories that can also help you determine if you're missing any tasks for the story to be done.

Let's walk through an example to make sense of all this. Let's take the following user story, which came as a requirement for a web app:

As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it.

See Also

How to Write Test Cases For Login Page?Research Methods: Scenarios and User Stories | Nightingale BlogHow to Convert User Stories and Acceptance Criteria into Test CasesUser Story Testing | Test IO Academy

And with the following acceptance criteria:

"Given that I am a registered user and logged out..."

1. "...if I go to the log in page and enter my username and password and click on Log in, then the data associated to my user should be accessible."
2. "...if I go to the log in page and enter my username but an incorrect password and click on Log in, then log in fails with an error message that specifies that the username or password was wrong."
3. "...if I go to the log in page and enter my username and password and click on Log in, then my user login session is loaded in less than eight seconds."

And let's assume the definition of done for all user stories includes things like ensuring that code adheres to standards and style guidance and that it's properly tested.

By getting all the developers together to brainstorm what is needed, you're likely to hear things like:

• "We need a new UI element for Sign-up and Login"
• "We need to develop encryption functionality for the password"
• "We need to create a table in the database for user information"
• etc.

Now, to do things in a more structured way, let's ask ourselves (the team):

1. How can we break this down into executable, scope-bound tasks? Here the team may agree on the following tasks for the user story:

   • Define Sign-up/Login form style and develop new CSS class
   • Develop HTML and Javascript Sign-Up/Login presentation layer code
   • Develop Javascript sign up form validation code
   • etc.

2. Will acceptance criteria be met upon execution of all the tasks? Here the team looks at the acceptance criteria and concludes the following:

   • The second acceptance criterion would not be met without developing an error page or message. The team then expands the scope (description) of the task "Develop HTML and Javascript Sign-Up/Login presentation layer code" to include an error message. A new task just for this would be too small.
   • The third acceptance criterion refers to a non-functional requirement. The team realizes it cannot be sure it will be met without proper testing, so it adds the task: "Run performance tests on the login function".

3. Can the user story meet the definition of done given the tasks? Here the team runs through the list of items that determine an user story is done, and it concludes that two new tasks should be added to this story to ensure its completeness:

   • Write and run regression tests
   • Update change log to describe new sign-up/login functionality added

Now you can see the task list has grown a bit just by asking ourselves these questions. Naturally, after doing this exercise a few times, the team will start thinking about these questions from the start and will become better each time at coming up with secondary tasks such as testing- or documentation-related ones to make sure important details are never forgotten and delivery is accepted.

When you have more clarity on the list of tasks that go within each user story, it's time to estimate effort. Here, important things to consider are:

• Dependencies and downstream tasks: Are there dependencies or building blocks for this task that must be developed or modified?
• Complexity and team skills: Do the developers have the necessary skills to tackle this task? Or will they need some time for research and learning?
• Past estimates: Are there past estimates for similar tasks the developers can draw on to better estimate the current task's effort? Has someone done something similar before?

In Agile, teams will most often use estimates in a unit of measure called story points, as opposed to actual time estimates (such as hours or days). Story points are numerical values that follow a modified Fibonacci growth sequence, such as: 1, 2, 3, 5, 8, 13, 20, 40 and 100. They represent levels of effort that can be more easily compared to one another due to the relative nature of the scale. For example, although it's hard to gauge how much a level five effort is different from a level six effort (a 20% increase), there's a more clear difference between a level five and a level eight (a 60% effort increase). In the lower range of the scale, the absolute difference is small but the relative difference will still be high (for example a level two is double the effort of level one). It's this constantly large relative difference between one level of effort to the next that makes this system work.

What Agile teams must agree on (or eventually learn through experience) is just what a single story point corresponds to in terms of actual work effort. Then, everything else can be measured in relation to that. Story points take time out of the discussion, because time is not always a reliable metric. If, for example, during a specific week every team member is busy with other corporate responsibilities, such as training or interviewing, then every task would need to be re-estimated with artificially high numbers of days (which would cloud the real effort behind them). With story points, the effort estimation always remains true. The actual delivery dates will vary with the team's availability, but this is understood from the start.

When it comes to estimating story points for tasks there are a few techniques that can be helpful. Two of the most commonly used ones are Planning Poker and T-shirt Sizing.

The idea of the Planning Poker "game" is simple, and can be summarized in the following steps:

1. Each team member gets cards corresponding to story points' values (1,2,3,5, etc.).
2. The product owner goes through each user story, and ask the team to individually estimate a level of effort for the story based on the tasks involved.
3. Each team member picks a card that corresponds to what they estimate the story points for the user story are. They should not show their cards to each other or start any discussion at this point. This is a way to enrich the estimation process by not having anyone influence any other team member, but instead to let each one offer their individual perspective.
4. Everyone shows their cards. If there's consensus (i.e. very low variance in the results), then the story points can be easily assigned to the user story (the most commonly picked card being the most reasonable choice), and the team can move on to the next. If there's no consensus, or some wildly different estimations are presented, then each team member is given the opportunity to explain his or her decision, clarifying any misunderstandings or misplaced assumptions. After this, the team repeats steps three and four in light of the discussions that took place.

Steps three and four are repeated until consensus is reached. An example of consensus in a Planning Poker session with a team of six developers would be 3-3-2-3-5-3 (three story points would be a reasonable choice).

For the same team size, an example where consensus is not reached and another iteration is likely required would be 3-8-3-2-5-8 or 3-3-3-13-3-5 (one "player" disagrees strongly).