How I Split Work: Recap

First off, thank you to everyone who has read my posts this will be the last one of the series. Today I will be recapping the series into a much smaller set of notes so you can bookmark this page for later.

1. Pitch
   1. Elevator pitch or more of user features and experiences.
   2. Enough to sell you on the idea
   3. Could come from anyone
2. Cut
   1. Take the pitch and cut out fluff, emotion, examples or unnecessary details
   2. Technical details are also cut and can be saved for the very end
   3. We end with a bullet point list of requirements
3. Merge
   1. Combine any bullet points that are very similar and can be handled together
4. Abstract
   1. Anything too specific can be abstracted up a level
   2. We end with a clean set of requirements
5. Detail your end results
   1. Blurb every idea you have
   2. You may need to trim down some ideas to fit your timeline, but I like to keep them all somewhere for later
   3. Check each idea to make sure it is viable and even possible
6. Detail how users start the experience
   1. Match your end results and requirements to what you will need
7. Draw it out
   1. Take the start and end to draw out a graph leaving a gap in the middle
   2. Fill in the middle, lining up the start and end parts with the requirements
8. Break down
   1. Take any abstract, high-level node and add details
   2. Split any merged requirements into separate nodes
   3. Make note of any edge cases and abort conditions
9. Review
   1. Get someone else to review your chart, preferably someone who wasn't part of the process
10. Cleanup the chart
    1. Optional: If you want to clean up your graph and maybe upload it somewhere
11. Order
    1. Start with closing the start > finish loop
    2. Then get the program to work correctly ( sometimes this is done already )
    3. Then handle any skipped edge cases, usually saving exceptions for last

If at any point you feel things are not lining up or feels a little off, maybe even too big. Stop and go back a step or two and try again. More art than science here, quickly doing one or two iterations until you are happy is better than being far off later.

Now you can start working, follow the style you prefer. I recommend TDD ( test-driven development ) or XP ( extreme programming ).

That is it, thank you for reading this series.