elephant carpaccio
DESCRIPTION
For agile development to work well, it is important to have many small stories and many small tasks. This presentation will show how to divide epics into minimal achievable stories and how to decompose stories into minimal achievable tasks.TRANSCRIPT
Elephant Carpaccio*Lars ThorupZeaLake Software Consulting
August, 2011
* thanks to Alistair Cockburn
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
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?
Big slices are hard to fit into the schedule
Start Release date
Time
Smaller slices are easier to fit in
Start Release date
Time
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
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
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
Different stories for different users
Cable Modem
DB
Middle Tier
Web Services
UICable ProviderUser
Cable ProviderScripts
NetworkInterface
CLI
Vendoroperator
Generic Modem
Interface
Final set of stories for the epic● Connect
● CLI● Web Services● UI
● Disconnect● CLI● Web Services● UI
● Monitoring● CLI● Web Services● UI
● Usability Improvements
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
Layers involved in this story
Cable Modem
DB
Middle Tier
Web Services
UICable ProviderUser
Cable ProviderScripts
NetworkInterface
CLI
Vendoroperator
Generic Modem
Interface
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
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
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
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
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!
But: When do I stop the breakdown?● Stories can be arbitrarily
small, e.g. bug fixes● The overhead is always worth
it because the freedom to prioritize prevents a lot of waste
● Don't make tasks too small● A task of a few hours need not
be broken down further● Don't make every new
database field a separate task● 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
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
But: <your question here>