How I Split Work: The Great Filter
Tags: agile, workflow, productivity, beginners
Published: 2020-01-09 06:07:47

---
title: How I Split Work: The Great Filter
published: true
description: Step by step process on how I go about splitting work
tags: agile, workflow, productivity, beginners
series: How I Split Work
---

In the last article, I introduced our pitched idea today we will be doing a two-pass on the pitch to nail it down to a bullet-pointed list of requests. The goal here is to remove any fluff, emotion, examples or unnecessary details.

Note that these details are still important, but we can ignore them until we get further along.

## Cut
The first pass will go through and cut out bits. So let's go through a phrase at a time.

> We would like to be able to process an entire order for our customers at once.

This is a great high-level overview of what we are building however, it is too vague to help us make our plan.

> In doing so, accepting multiple tickets for any number of movies at once.

This next sentence provides our first requirement, multiple tickets at once. The rest of the sentence can be cut.

> We are also in a small town and repeat customers are very important to us

Entirely fluff and can be cut.

> we want to offer a military and senior discount with the option of special promotions later

This provides two requirements, military and senior discounts. It also brings up special promotions later which may influence how we build our system. This also adds our first question to ask, how much are these discounts.

> We currently only accept cash, so we will need to make sure we handle returning change.

Great, we only accept cash and will not need to worry about other forms of payment.

> We only have a few screens and to keep it simple for us

This might help us, but as we will see later data within our pitch can generally be ignored. The only parts we want to keep an eye out for are things that are single versus lists. There really isn't much difference between 2 and 20 pieces of data at this point.

> each screen will only play a single movie all day.

Cool, this will help us build our data structures later.

> However, we will have on some occasions special events where we play two different movies back to back.

Hmm, this kinda contradicts what we just read above. We will want to handle this in the second pass.

> Our pricing is broken down by time and day, during the week ( that is Monday through Thursday ) and before 6 pm we have our cheapest prices. After 6 and weekends before 4 pm, we have our middle level and weekends after 4 pm are the most expensive.

This is a lot of details on how movies are priced, we will want to save this.

> We also offer an adult-only night on the first Monday of the month where no children tickets are sold.

This sounds like a prime example of a weird edge case, not that I dislike the idea but we will have to add additional logic here without question.

## Making the Cut
Now that we went through our pitch, what sort of requirements do we have now? Well, let's just grab the sentences we thought were important and make an ordered list.

1. accept multiple tickets for any number of movies at once
1. military discounts
1. senior discounts
1. special promotions
1. only accept cash
1. screens only play one movie a day
1. special events will play two different movies back to back
1. cheapest tickets during the week before 6 pm
1. middle tickets during the week after 6 or weekends before 4
1. expensive tickets weekends after 4
1. no child tickets sold on the first Monday

Great, looking good so far but we can do a little more work here. Time for pass 2.

## Merge or Abstract
Our list is great but before we move on we can do a few operations to make the following steps easier. The first thing we can do is to merge similar items together. The second thing is to abstract details out that we do not need to know until we start coding.

### Discounts
Discounts are a good example of something we can merge together. In the end our system will probably not care much if it is a military, senior, referral or some other sort of discount. All of them will have some sort of percentage applied and they either will stack or not. Therefore, we can combine our 3 discount requirements into one. Later on, we may unmerge these but they could end up just being part of a map and not need to.

### Ticket pricing
How we calculate the cost of a single ticket is critical. However, at this stage we do not care exactly how the cost is calculated only that there is some logic to do so. So we can abstract all the logic and details of timing and days into one requirement.

### One movie a day or not?
Currently, we have two requirements that seem contradictory. First, we say a screen only plays one movie a day, then we also say there are sometimes special events that will play two back to back. Well, what do we do?

I like to not have special cases, even for special events. Instead, I prefer to abstract or merge requirements that will satisfy both at once.

Therefore, I would batch these two together and simply say any screen can show any movie. Now, saying anything can do anything is really the same as no requirement at all. So, we can remove this one entirely.

## Requirements List
After those two passes, we now have a cut, merged or abstracted list of:

1. accept multiple tickets for any number of movies at once
1. allow discounts and promotions
1. only accept cash
1. tickets will have varying costs
1. no child tickets sold on the first Monday

Now if you notice, this is a very short list of requirements. Much shorter than our original pitch. This is fine, we will be adding more to this later on.

Thank you for reading.