The ultimate goal so far: Chunks

So the title is set. Let's find out why I set the goal to chunks and what do I mean with chunks. Well, chunks are of course bits of pieces kind of glued together. They represent a new definition of amount coming from a bigger piece. See it like this: when you need to remember a phone number, the best way to remember it is divide it into... right chunks. Let me first lead you to a similar situation.

Some history first

In the earlier days, there where no books in the world except one in a library in for example Egypt. Now days when people need a book they buy it and put it on the shelve. You now have a piece of knowledge standing in your own house. And when you want to access it, you just pick it up from the shelve, search by index and find what you're looking for. In the beginning of our era, when you wanted knowledge, you had to go the a library (and traveled hundreds of miles for it) and memorize a book. For that you needed some tools to place information into your brain. When you did, you had a book standing on a shelve in your memory. And when you wanted to access it, you just picked it up from you memory, searched it by index (and believe me, you can) and find what you're looking for.
At that time you did not have calculators like we have and people where trying to find ways to memorize the best way. There are good ways to memorize information from a book, but also for storing constants. Here is where I want to get to the chunks part.

Chopping for fun

Now days, people are trying to memorize numbers for fun. You probably all seen a show on television where some dude or girl tries to numerate the number Pi. We are all surprised to see how many digits someone can memorize, but they have a system for it! They try to think in patterns and most of all, they do that in chunks of numbers. Here is an explanation of how you could memorize Pi: http://www.michael-hogg.co.uk/pi.php. You see Michael Hogg has divided the digits into chunks of four, five or pairs of three. Like a phone number, it's hard to memorize it from the whole line with ten characters. For example it's hard to memorize 0659526465 if you leave it in one piece. But if you split it up and find a pattern then you can remember it much easier: 06 595 264 65 or 06 59 52 646 5. You see, it becomes easier to remember? And I believe this way of chunking is useful for our epic and user stories.

Getting started?

Maybe you are eager to get started with chop your user stories into bits of pieces, but first hear me out. There are a few questions we need to answer first:

• Why do you even want to have chunks at all? 
• Does these chunks of work help me in my sprint?
• Should these chunks all be the same size?

Lets pretend that we have only chunks in our backlog. All these chunks are the same size. They are small and well defined. They have patterns and testable value. Because the size is small, we know exactly what to do with it and they bring no confusions. That's because we defined them ourselves before we take them into the sprint. And there are some things you might want to consider.

• If you already got the scenarios first for your user story which you wanna split up, you could look for different patterns. There is maybe a test scenario to check whether the button should be enabled and when it is, there are scenarios to check what happens when the button is clicked. Maybe there are keyboard shortcuts as well, who knows. You see, you have three different kind of scenarios focusing on three different aspects of one user story.
• If you don't got the scenarios first, consider creating some within the refinement.
• I know that we're trying to deliver a user story that provides user functionality, but you can split this previous button scenario up into three chunks. The first one is just to enable the button by authorization on user level. The second is to see if the button responses to keyboard shortcuts. And the third one completes the former user story and checks the functionality. 

And no, the user cannot do anything with a button which he or she can click on and does nothing. But the tester can almost sit next to the programmer changing this small change in the code and test it right away. You then have minimal technical debt, cause everyone knows exactly what to do and what the tester should test and you have minor code changes in one chunk. And most of all, you get closer to continuous delivery!

I think if the product owner sees the advantages, he agrees having such poor functionality. At the end of the day when you implemented 5 or 6 chunks, 2 or three of those will have full functionality.