Here are some tips for breaking down work in an agile way: - Focus on delivering value to users. Each story and task should provide some value. - Iterate frequently. Stories and tasks should be small enough that you can complete and release them within a sprint or two. - Get early feedback. Small slices allow testing work sooner and adjusting based on feedback. - Prioritize flexibility. Small slices give you options to reorder or drop work as priorities change. - Estimate costs accurately. Tasks should take 1-5 days; if longer, may need refactoring. Consider spikes for technical challenges. - Refactor when repetitive. If work is very similar, look for ways to simplify through ref

1. Elephant Carpaccio*
Lars Thorup
ZeaLake Software Consulting
August, 2011
* thanks to Alistair Cockburn

2. Who is Lars Thorup?
● Software developer/architect
● C++, C# and JavaScript
● Test Driven Development
● Coach: Teaching agile and
automated testing
● Advisor: Assesses software
projects and companies
● Founder and CEO of
BestBrains and ZeaLake

3. How do you build an elephant?
● One slice at a time
● To be agile is to be able to build complex software from
very thin slices of functionality
● How do we do that?

4. Big slices are hard to fit into the schedule
Start Release date
Time

5. Smaller slices are easier to fit in
Start Release date
Time

6. Agile: the value of short feedback loops
● Provide value faster
● release to client monthly or quarterly
● release to test weekly
● integrate daily
● Get feedback faster
● from testers and users
● cheaper to fix bugs and adjust functionality
● Adjust faster
● adapt to changed conditions
● change priorities
● track progress early

7. Thin slices
● How do we break down new functionality (an epic) into a lot
of small slices (stories)?
● How do we break down a story into a lot of small tasks?
● In the following
● an example based on domain of cable service (broadband internet)
● then some general observations and suggestions

8. Breaking an epic into small stories
● "As a cable provider I would like to have commands and
monitors so I can connect or disconnect cable service
to this customer"
● How do we break this epic into smaller stories?
● Each story must have value for a user
● Different users might use these capabilities (Vendor operators,
Cable Provider automation, Cable Provider operators)
● Commands and monitoring provide value individually
● Connect and disconnect provide value individually
● Further usability improvements is spawned off to its own story
● Include test and documentation in each story
● We will not treat each individual command as an individual story

9. Different stories for different users
Cable Provider
UI
User
Web Cable Provider
Services Scripts
Generic
Middle Network Cable
Modem
Tier Interface Modem
Interface
CLI
DB Vendor
operator

10. Final set of stories for the epic
● Connect ● Monitoring
● CLI ● CLI
● Web Services ● Web Services
● UI ● UI
● Disconnect ● Usability Improvements
● CLI
● Web Services
● UI

11. Breaking a story into small tasks
● "As a Cable Provider Script, I want to read the modem
status flags so that I can obtain the state of a particular
modem in the field"
● How do we break this story into tasks?
● Implementing support in each layer becomes a task
● Consider spawning off exceptional cases, optimizations, larger
refactorings as individual tasks
● Add a spike task if using new technology (tools, APIs, ...)
● Story documentation and story acceptance tests becomes individual
tasks
● Include unit tests and direct refactorings as part of each task

12. Layers involved in this story
Cable Provider
UI
User
Web Cable Provider
Services Scripts
Generic
Middle Network Cable
Modem
Tier Interface Modem
Interface
CLI
DB Vendor
operator

13. Final set of tasks for the story
● Acceptance tests for the story
● Development (design + code + unit test)
● GenericModemInterface::GetStatus (supported by modem)
● Database script for new flags
● MiddleTier::GetStatus
● Spike: best practice for flag support in WSDL
● Refactor WSDL: explicit support for flags elsewhere
● WebService::GetStatus
● WSDL::GetStatus
● GenericModemInterface::GetStatus (unsupported by modem)
● User documentation update for the story

14. Stories - how small?
● Divide story S into S1 and S2
● ...if both S1 and S2 has individual value for some user
● no matter how small the value
● (larger than 0)
● ...if releasing S1 or S2 to test or production provides
valuable feedback for the team
● Rule of thumb: several stories per developer per week

15. Tasks - how small?
● Divide task T into T1 and T2
● ...if both T1 and T2 contribute to the story, and have
individual cost to implement
● no matter how small the cost
● (larger than 0)
● ...if implementing T1 and T2 seperately does not increase
the cost more than 5-10%
● ...if comitting T1 or T2 provides valuable feedback for the
team
● Rule of thumb: several tasks per developer per day

16. But: How do I break down epics/stories?
● Breaking down an epic
● Find all the possible types of users
● List all the different variations that each user might get value from an
epic
● Ask yourself: As a user, what would I want to have if I could only
spend half the current estimate?
● Breaking down a story
● List all the places in the code that needs to be changed
● Each code change that can be individually unit tested becomes a
task
● Bundle code changes that are so similar that splitting them into
different tasks have too large overhead

17. But: What if the slices are still too big?
● A task with lots of repetitive work taking several days
● Is the design really optimal?
● Maybe it's about time for a major refactoring
● A story with lots of similar tasks taking several weeks
● Same thing: consider refactoring your design to make it cheaper to
implement this kind of functionality
● A task with technological challenges and weak estimates
● Do experiments and spikes in separate tasks
● A task to implement a major refactoring taking several days
● Read the Refactoring book by Martin Fowler et al.
● Split the refactoring into individual core refactoring tasks
● This will also minimize the risk!

18. But: When do I stop the breakdown?
● Stories can be arbitrarily ● Don't make tasks too small
small, e.g. bug fixes ● A task of a few hours need not
● The overhead is always worth be broken down further
it because the freedom to ● Don't make every new
prioritize prevents a lot of database field a separate task
waste ● Bundle related database fields
in a single task
● Very small tasks do not
improve the value of progress
tracking
● You can always commit your
work several times during a
single task if you like to work
in very small steps

19. But: What about bugs?
● A bug found before release becomes a new task
● Remember to add a failing unit test before fixing the bug
● A bug found after release becomes a new story
● Remember to add a failing acceptance test or unit test
● Try to come up with a process improvement that would have
prevented this bug

20. But: <your question here>