Within Agile/Scrum, the Task represents the smallest chunk of work during a Sprint. An item in the Product Backlog is decomposed into Sprint Backlog items. One Product Backlog item can result in several Sprint Backlog items. The newly created Sprint Backlog item is further decomposed into User Stories. Each User Story is, once again, decomposed into smaller pieces as Tasks.
There are several ways to slice up work too. You can add Epics or Initiatives to the fold, but that’s for a much larger scale project hierarchy. And now you know.
Regarding the increment of time, a task should take, there are several schools of thought (an excellent way of saying opinion) on this. In general, my (Ryan’s) view is that a task should be an item that takes no longer than a day to complete. But, but, but...
However, this is based on straightforward coding tasks that can be broken into sections. If you have a documentation team working on a piece of “how-to” for the project or a task that requires deep (days worth) research, I wouldn’t expect the job to be completed in a day.
This is where proper sizing and estimating come in. It’s been my experience that estimating is a mix of time and difficulty (among others). When assessing on a scale of one to five, I’d recommend time estimations (more on estimating below) as 1 being a half-day or less, 2 being a full day, and 3+ being more than a day. Each team is different, so if tasks routinely take three days or more, your time estimation for tasks may have 1 equaling three days.
Here’s another visual of the flow.
| Product Backlog | Sprint Backlog | User Stories | Tasks |
|---|---|---|---|
| Product Backlog (1) | Sprint Backlog (1.a) | User Stories (1.a.i) | Tasks (1.a.i.(1)) |
| Product Backlog (2) | Sprint Backlog (1.b) | User Stories (1.a.ii) | Tasks (1.a.i.(2)) |
| Sprint Backlog (1.c) | User Stories (1.a.iii) | Tasks (1.a.i.(3)) | |
| Sprint Backlog (2.a) | User Stories (1.b.i) | Tasks (1.a.i.(4)) | |
| Sprint Backlog (2.b) | User Stories (1.c.i) | Tasks (1.a.ii.(1)) | |
| User Stories (1.c.ii) | Tasks (1.a.ii.(2)) | ||
| User Stories (2.a.i) | Tasks (2.a.i.(1)) | ||
| User Stories (2.b.i) | |||
| User Stories (2.b.ii) |
Now that we’ve decomposed everything, we’re ready to write our Tasks. Rule one, keep it simple. Simple is easy. You can expect a User Story to have at least two Tasks (but be agile). Break it down into as many as you need to build the User Story into a functional “thing.” The Tasks can be created to suit a cross-functional team by organizing them by function, such as documentation, code, test, or UX. This will allow team members to work in parallel on their area of functional expertise to complete the story as a team.
Likewise, some people feel that it's "anti-agile" to have "too many tasks" for each story and fear it will introduce overhead, such as estimating, monitoring, or tracking tasks. One option teams have to minimize these processes is to create tasks, perhaps just with sticky notes on a physical task board.$^1$
Break Down Agile User Stories into Tasks and Estimate Level of Effort
Where a User Story is typically a functional requirement (as used by the end-user), Tasks break those down into small incremental units of work. They can be restricted to a single type of work, usually done by one person within a day (see above).
Wanna you see something crazy?
[verb] [action applied]
That’s the whole formula (that works for me). Taking our “formula,” we can turn this into something that looks like this:
Create a trigger for the cloud IOT software to know when a door is open.
There’s not much to it. So long as the task supports the User Story’s completion, it’s all good.
A Task card may look something like this (outside of any software solutions the Scrum Master is using):