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>