Skip to content
Home » Blog Posts » Small slices are the key

Small slices are the key

Lots of small slices grow into big features so start small.

Teams always want to produce a version of the app as soon as possible. It always seems to take longer than expected. Even when you know that it will take longer than you hope.

Despite this, most teams seem to design larger chunks of functionality. They feel each part is important. Almost nothing can be left ‘for later’.

This practice runs counter to two main issues with development. First, we’re still learning, and need to validate assumptions about what the people, who’ll use the app want/need. Second, the more that is included in the chunk, the more complicated its development is going to be.

Photo by Leonard Reese on Unsplash

Each slice is a potential release

The app needs to be shown to the people, who’ll use it for their validation. Ideally, the team talks to them before they start building the app to discuss their current solutions to the challenge, and find out what an ideal solution might include. This stops the team building the wrong features.

Smaller chunks of work are easier to monitor and build than larger ones. This means the team holds less stuff in their heads during the building, as it is all clearer how the parts fit together.

Combining both of these into small vertical slices means the team can potentially release each slice for feedback and validation. This provides a learning opportunity for the team. They learn (a) whether the architecture they are using is feasible, and (b) the community of their app confirms they are building something useful.

Smaller chunks are also faster to develop and deploy than larger ones. This makes progress feel more tangible.

Use story mapping to determine the slices

Story mapping, developed by Jeff Patton, aids the visualisation of the ‘whole app’ so the team can find the key elements that form the skeleton of the application. Then they can add more features to the bones of the skeleton.

The goal with story mapping is to determine the ‘bare bones’ of the app: what’s absolutely crucial, and what can be ‘deconstructed’ into something simpler at the start of the journey? For example, instead of lots of choices, can we start with a short list of three items? This also means search isn’t needed too, and we probably don’t need a database.

From the story mapping exercise you can also determine the essential path to always provide value to the people using your app. Some call this an MVP, but I try to avoid that loaded term. I prefer simple, lovable, complete.

Teach these ideas to your people

These ideas might seem counter-intuitive, but they work. You might think: bigger chunks mean more value, but that is wrong. Bigger chunks mean more delay, and fewer opportunities for you to change direction as you learn more about the app. Go look at the pizza app example for more ideas.

You can also use the ‘get out of the door’ exercise with people to help them understand how to find the backbone of the app. This version describes the exercise in Miro, but it works well in person too. Just get teams to use stickies on walls and windows, if you don’t have large tables for each team. There are also other variations if that seems more useful. I always do the ‘out the door’ and then ask the team to apply the idea to their own app to find the essential components.


This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.

If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn

The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.

Cookie Consent with Real Cookie Banner