Software Developers Should Deliver Thin Slices of Functionality

Imagine you’re on a team developing an e-commerce site for a traditional retailer. The product owner has a great idea about the Store Locator feature. However, as you start discussing this story, you begin to wonder how many iterations you will take to develop the functionality.

Photo by Suzy Hazelwood

Let’s consider there requirements for this feature:

1. Users can search for a store by zip code or city and state:
2. The application will display the five closest stores with their address, phone number, and store hours.
3. The page will show a map with the five nearest stores, with the ability to zoom in and out.
4. The search results will also show the regional manager’s name, phone number, email, and picture.
5. If the user is logged in, let’s pre-fill their address to search.

Too much at once

After thinking about this story or feature, you decide that it’s too much work for one pair to complete in a week and might even be too much to complete in two weeks.

What can you do?

You think about breaking it up, so you complete the domain models and services in the first week and then the user interface during the second week. This approach could work, but there are a few problems.

First, will the models you develop during the first week sufficiently complete the user interface without changes? Will they have enough functionality, and will the functionality be correct?

Second, what will you tell your product owner when he asks how the story is going? Will you give say that you’re 40% done? If you are 40% done, when will you be all done? More importantly, will you be able to show any functionality along the way?

Finally, if someone offers to help with this story, will you be able to hand off any tasks? Can any of the work be done in parallel?

Breaking up your story this way, focusing on models and services first and then on the user interface, leads to many difficult questions. The answers, unfortunately, are either “no” or “I don’t know.”

So what can you do to improve the situation?

Strands of functionality

What if you take this story and instead re-word it into several end-to-end features? Each piece of functionality is much smaller. Once complete, you can demonstrate each part to the product owner. Once some critical elements are done, you can develop other features in parallel. Finally, once the product owner starts to see this story built out, they may have different ideas or want to change direction altogether.

So what do we need to do to give our team all these options?

First, let’s break this story down into features. The difference is subtle, and development teams may use these words interchangeably.

I like to think about a feature as a single, end-to-end piece of functionality that adds value to the user.

So how can we break the Store Locator story down into some constituent features? Here’s one way:

1. The user searches by zip code and sees a list of stores with addresses and hours.
2. User searches by address.
3. Results are displayed with a static map.
4. The map can zoom in, zoom out, and pan.
5. Display the regional managers’ names, phone, and emails.
6. Display the regional managers’ pictures.
7. Pre-fill the search when the user is logged in.

Good for everyone

When we think about this story by features this way, a lot of opportunities open up. Each part is small, focused, and therefore easier to develop. After the initial search with results is developed, you can create features in parallel. The product manager will be able to see real progress much more straightforwardly.

The individual features can be prioritized amongst each other and other stories so that only the most valuable features are developed.

Though I initially looked at breaking up the stories from the product owner’s perspective, there are also benefits for the developer. The most significant advantage is that developers can focus on just one slice of functionality at a time. Concentrating on one portion is much easier to think about than the original, full story. For example, you can focus on search without worrying about maps or regional managers. In addition, when working on a significant story, it’s hard to know where to start. Breaking it down into thin features makes it much easier to focus.

Working on thin slices is also a lot of fun to develop. The combination of quick wins and rapid feedback energizes developers. In addition, the laser focus of the features keeps their mental stack light.

Nuances

Breaking a significant story into small, thin slices is not always forthright.

The key is to consider what brings the user value and what you can demonstrate to the user. You don’t want your stories to be too thin, so there is nothing to show. Instead, you want them to go end-to-end through your system, from the user interface, into your domain logic, persistence, and even collaborating systems.

This example isn’t made up or theoretical. It came from an actual project I worked on. We refer back to it often as an excellent way to add functionality to our system.

Takeaway

Once you have demonstrated working functionality, you are in a position to get feedback to make a spectacular system. This provides a fertile ground for controlled innovation and growth because it all starts with demonstrating value.

Focus on thin slices of functionality and continuously stay in this sweet spot of value and innovation.

👏🏻 Give me a clap and “follow” if you enjoyed this article.

📋 About Milo

I am a tech executive, writer, speaker, entrepreneur, developer and inventor. I’ve been developing software since 1995 and developing teams for the past decade. 🚀

I write articles about software, engineering, management, and leadership.

You can also follow me on Twitter. 🐦