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

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:

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:

And with the following acceptance criteria:

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

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:

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

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:

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:

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).

This technique simplifies the effort estimation by using even bigger "buckets" for relative measures, which correspond to the t-shirt sizes XS, S, M, L, and XL (or an even smaller subset). A process similar to that of the Planning Poker can then take place to reach consensus on the effort of each user story, which should be easier to do given the fact that it involves fewer size options and it brings the discussion to a higher level (with measures such as "small" and "large" as opposed to numbers). For this reason, this technique often speeds up the estimation process. It's also a good way to introduce a team to Agile and the idea of relative estimation.

Breaking down user stories into tasks and estimating effort is not something for the product owner to do alone. The key themes underlying techniques for estimations in Agile are the objective of reaching consensus and the iterative nature of the process. By using the relative measure system of story points and by involving the entire team in the estimation process, a high fidelity estimation tends to emerge (or at least better than what would otherwise be obtained through traditional methods). By removing time from the discussion, expectations become more realistic and teams are better able to gauge the complexity involved in their work.