Story splitter

…umpf, a big chunk.

✣  ✣  ✣

Get a big thing done.

Why split stories?

• Reduce uncertainty
• Early and faster feedback
• Easier time estimation
• Faster value to customer
• Visible work progress—visible flow
• Clearer responsibility
• Earlier start of work/code/test/execute
• Easier distribution across team
• Easy to debug
• Easy to test and validate

See small is beautiful

Therefore:

Split it into bite-sized chunks that each deliver value.

✣  ✣  ✣

✣  ✣  ✣

Because small is beautiful, there is a strong preference for small items, as they:

• enjoy shorter short cycle times;
• show more progress on the kanban board;
• take less effort to complete;
• are easier to understand;
• are easier to test and accept;
• provide a predicable and continuous flow that facilitates expectation management; and
• make “past results are a guarantee for the future” come true, just like yesterday’s weather.

To be specific, in planguage this looks like:

Small Stories
Scale	Average number of days per item.
Meter	Track the number of days per item in a control chart.
Wish	≤ 2 days
Goal	≤ 3 days
Must	≤ 5 days
Now	20 days
Therefore	Split items until: the item has exactly one crystal clear acceptance criterium (or scenario) specified in gherkin; and each feature consists of ≤ 4 user stories; and each user story has ≤ 6 tasks. Identify and discuss outliers during or right after the daily standup.

Sources

• SlideShare » Neil Killick » Effective Story Slicing
• Google Docs » Henrik Kniberg, Alistair Cockburn » Elephant Carpaccio Exercise Facilitation Guide
• Alistair.Cockburn.us » Alistair Cockborn » Elephant Carpaccio exercise
• Pareltaal » Martien van Steenbergen » Verhalenhakker
• InfoQ » Savita Pahuja » Empirical Measurement of Cycle Time by Slicing Heuristic
• xProgramming » Ron Jeffries » Getting Small Stories
• NeilClick.com » Neil Click » My Slicing Heuristic Concept Explained
• xProgramming » Ron Jeffries » Slicing, Estimation, Trimming