How I Split Work: Draw it out

Through the first four articles, we have achieved some really great results.
We were able to take an elevator pitch, filter just the important parts, analyze the end results and also the beginning.

At this point, we can take our notes and pitch it to our project lead, product owner or a similar role at our company. Or, we can take this back to our users and get their thoughts. For demo purposes, I will be skipping this review step but this would be the first time you could do one. Even if you do not review it with another group, it is still good to take your notes and just say them out loud. Rubber duckies work great here.

I prefer to do all drawing with pen and paper, but I will be using draw.io to share.

Our goal for this stage is to take what we have written down so far in bullet points and map it to a flow chart. We will be doing this twice, first for the user experience side and second what our internals need to be for that to work.

For reference our existing notes consist of the following:

1. Beginning
   1. Requested tickets for the customer
   2. Amount of cash they are paying with
2. Middle
   1. Accept multiple tickets for any number of movies at once
   2. Allow discounts and promotions
   3. Only accept cash
   4. Tickets will have varying costs
   5. No child tickets sold on the first Monday
3. End
   1. I should receive one ticket for each person
   2. My ticket should ...
   3. I should be given a printed receipt of the transaction
   4. My receipt should ...
   5. I should get the change back with my ticket

As with all our previous steps I do this in two stages. First, I write out the beginning and the end. Then, I fill in the gaps with the middle pieces.

Outer Rim

To start with we will be doing just the beginning and end stages with a magic "stuff" in the middle. The goal here is to force us to fill in that gap such that it makes logical sense and flows. If we were to start with the middle and work outwards we might assume we are given more than we are or that the end result is easier than we want.

Note: If you know UML you can use it here, I do not and just pick shapes that I like for different nodes. Our flow chart will never be so intense we need most of what UML offers. If you ever feel you need to do full UML you probably just want to split your entire task.

Plug the hole

As we do our next stage we want to get as many of our supported features as possible but only from a high-level description. We do not want to go into technical details here or try and explain every conditional situation. At the end of this, we can have another review with users or project leads all while speaking our native language.

The longer we can go without writing code the better. This might sound "unagile" or "waterfally" as we are spending so much time upfront but this should be cleared up later. ( If not, ask in the comments )

Explanation

If you notice I did not explicitly mention how to find the cost of the tickets or for what reasons a ticket would be unavailable. At this moment, I am choosing to hold off on those details. Because at this stage all that would do is cloud the flow and cause it to balloon in time required. This is all meant to be done quickly. We can get a pretty good understanding of flow with simple notes like this more than a full book.

We are also only focusing on the path that assumes all conditions are valid and no edge cases are hit. That is, we do not handle if the customer does not give us enough money or the ticket is not available. We will be handling these later.

Thank you for reading.