Your SlideShare is downloading. ×
0
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Elephant Carpaccio
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Elephant Carpaccio

3,937

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 …

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
3,937
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
52
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Elephant Carpaccio*Lars ThorupZeaLake Software ConsultingAugust, 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 usersCable 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 storyCable 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 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. 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. 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>

×