From stories to tasks: decomposition, dependencies and hours

A story on the board that says "book a lesson" can mean three hours of work or three weeks. The team has agreed it is worth doing this Sprint, and nobody can yet say what first thing to do on Monday morning. Breaking stories into tasks fills that gap, and it is the part of planning that belongs to the Developers alone.

What the Guide says

Topic Three of Sprint Planning is "How will the chosen work get done?" For each selected item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How it is done is at the sole discretion of the Developers, and no one else tells them how to turn Product Backlog items into Increments of value.

The result is the plan part of the Sprint Backlog, which the Guide describes as a plan by and for the Developers, with enough detail that they can inspect their progress at the Daily Scrum. Our post on the Sprint Backlog covers where this plan sits.

Two features of that description are worth underlining. The unit of one day or less is a size target. A task of that size lets someone say at the Daily Scrum whether it is done, which a task of five days never allows. And the sentence about "sole discretion" is what makes task planning a team activity and not a manager's.

What the SBOK adds

The SBOK® Guide treats it as two processes. In Identify Tasks, the committed user stories are decomposed into specific tasks and compiled into a task list. It can be done at the start of the Sprint for all stories or just before work starts on each. The Product Owner does not take an active part but stays available to answer questions. The tools are decomposition, which breaks stories down to the level where the team has enough information to create the deliverables, and dependency determination.

Two requirements in its description are easy to miss. The task list must include testing and integration effort, so the increment can be integrated with the work from earlier Sprints. And the level of granularity is decided by the team.

In Estimate Tasks, the team estimates the effort for each task, but the SBOK describes this as an optional process, to be done if the team sees value in it. Estimates can use the same methods as for stories, and the criteria can be story points or ideal time, meaning the hours a team member spends working only on the project's deliverables, without other activities.

How to decompose

A story becomes tasks by asking what has to be true for it to meet the Definition of Done and its acceptance criteria. Walk through a story with the Developers and list the work.

Here is an illustrative case. The story is "a member can request a room for a time slot", with acceptance criteria that a request is stored, a confirmation is shown, and a double booking is refused. Tasks might be:

1. Add a request form to the booking page.
2. Store the request and validate the date and slot.
3. Refuse a request that overlaps an existing booking, with a clear message.
4. Show a confirmation on screen.
5. Write automated checks for the overlap rule and the happy path.
6. Update the help text.
7. Deploy to the test environment and run through it by hand.

Notice what is on the list besides building: checks, documentation and deployment. They are there because the Definition of Done asks for them. A task list that contains only "write code" tasks produces stories that are nearly done and never done.

Some good habits:

• Split by work, not by person. A task is a piece of work. Who takes it is decided later.
• Include the unglamorous tasks. Review, test, documentation, deployment.
• Keep to a day or less. If a task is larger, it hides several.
• Do not decompose too early. The SBOK allows decomposing just before work starts on each story, which avoids planning detail that will change.
• Capture questions as tasks. "Ask the Product Owner whether refunds are partial" is work, and writing it down stops it being forgotten.

Dependencies

Dependencies are the other half of the plan. The SBOK says that once stories are selected, the team should consider dependencies, including availability of people and technical dependencies, and that documenting them helps decide the order of the tasks. It describes mandatory dependencies, which dictate sequence by the nature of the work or by contract or law, discretionary ones, which come from past experience or best practice, and external ones, which depend on things outside the team's control and therefore carry more risk.

You do not need the labels to benefit. What matters in practice:

• Which tasks block others? Build these first.
• Which depend on something outside the team? A test account that takes three days to approve should be requested on day one.
• Which depend on one person? That is both a dependency and a single point of failure.

A simple board lane, or a note on a task card naming what it waits for, is enough. The point is that nobody is surprised on day six.

Should you estimate hours?

The Scrum Guide does not require task estimates. It requires a plan with enough detail to inspect progress. The SBOK makes the estimation of tasks optional. So the question is purely whether estimating adds more value than it costs.

Reasons to do it:

• A sanity check. Adding task estimates and comparing the total with capacity can show that the Sprint is overloaded before it starts. The SBOK says the updated task list is used to decide whether the team should reduce its commitment or can take on more.
• A burndown. If the team tracks remaining work in hours, estimates are the data.
• Learning. Comparing estimates with actuals helps a team see where it is optimistic.

Reasons not to:

• Task estimates are rough and go stale. Tasks change as soon as work starts.
• It can become busywork. If the team spends an hour estimating tasks of a day or less, the hour may exceed the benefit.
• It invites tracking individuals. Hours against names tempt people to measure performance, which corrodes honest estimates.

A middle path is to size tasks only roughly, for example as small, medium or large, and to count tasks instead. For items of similar size, the number of tasks left is a serviceable measure of progress.

If you do estimate, use the same units across the team, say what is included (focused build time or all time, the SBOK distinction between ideal time and elapsed time), and keep the total beside capacity, not in place of it.

Common mistakes

• No testing or integration tasks. The SBOK says they must be there.
• Tasks that are really stories. If a task needs its own acceptance criteria, it is bigger than a task.
• Decomposing alone. The Guide gives this to the Developers as a group, because they know different parts of the system.
• Treating the task list as a promise. It is a plan, and it should change when the team learns.
• Hours as a performance measure. They are a planning aid.
• Never revisiting the estimate. The Daily Scrum is where the plan is adjusted.

How to practise it

In the simulator, the third and fourth steps break the committed stories into tasks, with their dependencies, and estimate them in hours against the team's capacity. You confirm the breakdown, then the estimates.