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. As you start to discuss this story, you start to wonder how many ITERATIONS it will take you to develop the functionality.
Users can search for a store by zip code or city and state. The five closest stores will be displayed with their address, phone number and store hours. A map will be displayed showing the five closest stores, with the ability to zoom in and out. Finally, the search results will also show the regional managers name, phone number, email and picture. Oh, and if the user is logged in, lets 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 that you complete the domain models and services in the first week, and then the user interface during the second week. This could work, but there are a few problems with this approach.
First, will the models that you develop during the first week be sufficient to complete the user interface without changes? Will they have enough functionality, and will the functionality be correct?
Second, what will 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 in this way, focusing on models and services first, and then on user interface, leads to alot of 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, each feature can be demonstrated to the product owner. Once some critical features are complete, other features can be developed in parallel. Finally, once the product owner starts to see this story built out he may have other ideas, or want to change direction altogether. So, what do we need to do to give our team all of these options?
First, lets 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:
- User searches by zip code, and sees a list of stores with address and hours.
- User searches by address.
- Results are displayed with a static map.
- Map can zoom in, zoom out, and pan.
- Display the regional managers name, phone and email.
- Display the regional managers picture.
- Pre-fill the search when the user is logged in.
Good for everyone
When we think about this story by features this way, alot of opportunities open up. Each feature is small and focus, and therefore easier to develop. After the initial search with results is developed, features can be developed in parallel. The product manager will be able to see real progress much easier. The individual features can be prioritized amongst each other, as well as among other stories, so that only the most valuable features are developed.
Though I initially looked at breaking up the stories from the product owners perspective, there are also benefits for the developer. The biggest benefit is that development can focus on just one slice of functionality at time. This is much easier to think about than the original, full story. You can focus on search without worrying about maps or regional managers. Often when working on a large sotry, 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 alot of fun to develop. The combination of quick wins and rapid feedback energizes developers. The laser focus of the features keeps their mental stack light.
It's not always easy, or straightforward, to break a large story down into small, thin slices. The key is to think about what brings the user value, and what can be demonstrated to the user. You don't want your stories too thin, so that there is nothing to demonstrate. You want them going end to end in 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 a real project I recently worked on. We refer back to it often as a good way to add functionality to our system.
Once you have demonstrated working functionality, you are in a position to get the feedback and iteration needed to make a really spectacular system. This is very fertile ground for controlled innovation and growth, because it all starts with demonstrating value. Focus on this slices of functionality, and continuously stay in this sweet spot of value and innovation.