Benefits of Agile Story Decomposition

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning – from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure – communicating the release schedule internally with your development team.

Overview of Structure

Even agile projects benefit from having a structured perspective on why and how to develop the software.

• Customers have goals, and those goals have value.
• Those goals are achieved through user stories (or use cases).
• Capabilities, usually defined in a specification, enable people to execute the stories.
• Development tasks represent the work that must be done to implement those capabilities.
• Tests can be defined to validate the capabilities, and assure that code is working as-designed.

Scheduling Releases

We’ve written before about communicating a release schedule with use cases. The fundamental concept is that you need to deliver actionable, valuable capabilities with each release. Since customers get value from goals by executing use cases, you need to deliver a complete use case (or user story) for the customer to get value from it. This also helps with the “why do I care about release X?” question – because it provides value.

Although your customers don’t need to know which development tasks are included in what release, your team does. And as a point of clarification, when you are scheduling the work that fits in the time box for a release, you absolutely can schedule tasks that do not add up to a complete use case. Sometimes all of the work required to implement a single use case can’t fit within a single time box. And there’s no particular benefit to trying to force it to always happen that way. It is more important to schedule the most valuable use cases (or user stories) first. And then communicate to your customers the releases in which those use cases are completed.

Nine Development Team Benefits

Doug Blis, at Visionpace, just wrote a good article listing nine reasons to divide user stories into tasks. He provides a couple of paragraphs of detail on each of the following reasons:

1. Iteration Planning
2. Iteration Burndown
3. Accountability
4. Shared & Individual Learning
5. Tasks Encourage Better Design
6. Forecasting Velocity
7. Tasks Serve as Reminders
8. Talk to the Dog
9. What if you hear “can’t/won’t task?”

These are all excellent how do we improve as a development team benefits. Managing your development team’s efforts at the task level provides enough data-points to improve, without being so much work that it hinders. Tasks are also the perfect size for extrapolation and improved estimation on future projects.

Getting Bigger Picture Benefits

In addition to your development team getting better by using tasks, you can improve your overall software delivery process. The key is to be able to clearly define the traceability for the project. Traceability won’t really help the development team get better at developing (which may be why not many agile proponents talk about it). But it will help you manage your project, and therefore the release schedule for your product. And that allows you to improve your relationships with your customers.

Better forecasting of tasks (combined with traceability) yields better forecasting of capabilities. And this also leads to better forecasting of user stories (or use cases). This allows you to spend less time dealing with changes to the schedule – and more time focusing on finding huge value for your customers. And fewer schedule changes result in better relationships, more trust, and higher profit (when you can leverage that trust into higher prices, and when you avoid the costs of schedule changes).
Do it so your development team gets better. And do it so you deliver better products, and build better relationships.