Elephant Carpaccio

5,847 views

Published on

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.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,847
On SlideShare
0
From Embeds
0
Number of Embeds
243
Actions
Shares
0
Downloads
77
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Elephant Carpaccio

  1. 1. Elephant Carpaccio*Lars ThorupZeaLake Software ConsultingAugust, 2011* thanks to Alistair Cockburn
  2. 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. 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. 4. Big slices are hard to fit into the schedule Start Release date Time
  5. 5. Smaller slices are easier to fit in Start Release date Time
  6. 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. 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. 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. 9. Different stories for different usersCable Provider UI User Web Cable Provider Services Scripts Generic Middle Network Cable Modem Tier Interface Modem Interface CLI DB Vendor operator
  10. 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. 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. 12. Layers involved in this storyCable Provider UI User Web Cable Provider Services Scripts Generic Middle Network Cable Modem Tier Interface Modem Interface CLI DB Vendor operator
  13. 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. 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. 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. 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. 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 its 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. 18. But: When do I stop the breakdown?● Stories can be arbitrarily ● Dont 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 ● Dont 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. 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. 20. But: <your question here>

×