Teach People to Slice Items Smaller

When we make everything small, then the work flows smoother.

People often find it daunting when they start to build larger applications. There are so many things to consider. How long with this take? Where do we start? What ‘exactly’ do we need to build? For beginners this seems really complicated, and it can be overwhelming.

The trick is to keep everything small. When you have fewer things to hold in your head, then it is easier to explore options too.

Tie everything back to a clear example

I have found it useful to discuss estimation and slicing with a clear example. This avoids team members getting lost in abstract concepts. Pizza works well across cultures, so I use it regularly.

Photo by Giorgio Trovato on Unsplash

I like to use an online pizza delivery example. Imagine your friend wants to test their online pizza business idea. They want to see if it’s worth spending time and money making this a real business. To test the idea they decide to make pizzas in their home kitchen. They ask your team to make a website for them to take orders. The site doesn’t need to be fancy. It just needs to test whether enough people like your friend’s pizza. Do they sell enough to cover costs and make a profit? Can they turn into a business?

At this point ask the people in the workshop to consider what does the website need. Have each team write out user stories for the site. Remind them this is for a small, basic online pizza store. When they’re done, we can turn to estimation to see how long it will take to build this site.

Estimation is a flawed process

With this example we can now introduce planning poker. You can use those planning poker, or estimation card decks that you’ve picked up at conferences. Tell them about t-shirt sizing, and that this should always be done by the team as whole. Show that the card decks come with different coloured ‘suits’ for each team member.

Ask each team to use the cards to estimate the stories for the pizza store. Given them plenty of time. Go around and check on them. It is challenging because they’ve not done this before. They always have lots of questions. That is good. It shows they’re engaged moving the theory into practice.

With a handful of stories they can start to estimate them and discover the joys of different opinions. Planning poker is wonderful for this part. It provides a process to pull assumptions into the open for discussion. Maybe this is the best part of it, as it helps to leverage the knowledge of the team. It also quickly shows why this should never be done by one person on their own. As the team discuss the stories, they learn more about each other’s experience, and knowledge, which helps the team.

You can also show that estimation is pointless too. Find the biggest story and ask questions about it: what makes it big? What happens if a person falls ill, or leaves the team? Show that the talking and discussion is the important part.

You’ll notice that we’re not explaining how to use story points to estimate velocity. We’re leaving that to one side, as it raises all sorts of other issues too.

Slicing is the key

Now you can tell them that some of these issues become more manageable if all stories are small. For example, if their biggest story is an XL t-shirt size menu, then ask them what makes it big. Point out they can start the menu as S or even XS t-shirt size. Ask them lots of questions to tease out their assumptions.

By encouraging teams to make everything as small as possible, you are helping them to clarify assumptions. For example, in the pizza store, why do we need a fancy menu to start? No, because we can start real small. We can use a static page, that only offers pepperoni or cheese pizza in 9″ size. Now the page is much easier.

Similarly, why do we need take all credit cards? Maybe we only take PayPal? Maybe we don’t even use a database, we just write to a file. Again, these are points to discuss with your people. Show them how these decisions depend upon the goal of the business. All of this is to serve the business, and nothing more.

Small slices let the team validate assumptions, and get lots of little wins. The little wins feel good, as you feel like you’re making progress. Finishing tasks, finishing stories. Seeing the site finish. Getting a little dopamine hit to make you feel happy each time something is done. This is more fun than bigger stories that take longer.

Small slices makes team collaboration much easier too. The team is able to coordinate their work more easily without extra pressure of trying to do too much.

Small slices do more too. They force assumptions into the open, and generate discussions. The clients can also see the work, and provide feedback sooner, which is ALWAYS a win.

Slices are vertical with a part of each layer

Each slice should include a part of each layer of the application, because these parts work together. Building the app in vertical slices forces you to acknowledge the message passing between layers. This also makes your work more visible to your client.

Vertical layers also force to the team to collaborate. The front-end people will need to talk to the back-end people to agree on methods, and variables. This will expose assumptions. The database people will need to talk to everyone. Vertical layers also mean you can see your work.

Yes, this is probably #noestimates

This is probably #noestimates. I tell my students about estimating, and then I tell them to forget estimating. Just slice everything so that it is about a day of work. Sure, it’s guesswork when they start, but eventually they will start to size things right. Then they can start to forecast how long something takes to go from being in the backlog to being ‘done’. No student team ever seems to do that, but they could. I point out this is what they could do, but they don’t.

Telling students to size things small, is more useful than teaching them about COCOMO+, or GANNT charts. Professional developers tell me they used them either ‘never’ or ‘over 20 years ago’, when they started. I ask this at at agile conferences and unconferences, or in Slack groups so it is a self-selected sample. It shows that a growing percentage of work is done without the planning tools of the past.

Ask your teams how they’d build an online pizza store. Find their assumptions. Teach them how to build it in small slices.

Teach your teams to slice stories, and they will find their work flows more smoothly.

---