Techniques for Breaking Down Technically Complex User Stories

Breaking down user stories to fit into a few days of work and still deliver value is a vital component of Agile and Scrum. This is what allows the Scrum team to get fast feedback on the work they are doing to ensure it aligns with customer needs. 

So what happens when the Product Owner can’t break down a story any further and it’s still too big to be manageable in a sprint? This creates a very difficult problem that the Product Owner and Development Team must work together to solve. 

In this post, we’re going to break down this user story:

As a datacenter technician, I want to be able to configure VLANs on a network switch from a web interface so I can easily make changes to any switch without being trained on the switch configuration process.

This kind of user story can be very challenging because there are a lot of complexities and unknowns contained within it. For example, the team might know that the switch must be configured through SNMP, but may have never used it before.

Looking at the Pieces

To start us off, we need to stop thinking about the story as a single thing and start looking at the pieces. So let’s set aside worrying about value and user stories for a moment and break down the steps.

One great way to do this is to take a stack of sticky notes and have the team draw the steps in the process of the user story on each sticky note then put them up on the wall. This lets the team quickly brainstorm the parts of the user story together. The picture below shows how this might look for our example:

Notice that these stay very high level. The goal is not to create a detailed plan of how this will be implemented, but rather to create a visualization of what is involved with the story. A good rule of thumb is that the Product Owner should still be able to follow along with minimal explanation from the team. This will be important for the next step in the process. 

It’s also important to remember that this doesn’t have to be perfect. If some of the steps are slightly off or missing, that’s ok.

Finding the Value

Now that the team has established many of the parts of the story, we can start looking for groupings with value. This is a collaborative conversation between the Product Owner and the team to identify what will add value and what will be technically plausible.     

You can see that a few things came out of this conversation. We’ve grouped the display of switch data into one story and the configuration change into another story. We’ve also de-scoped some of the steps. The caching has been set aside and the Product Owner understands the performance impact that has.  

We also decided that testing the change could be very complex and agreed that a simply validating would be sufficient for technicians to safely use the software, but we might keep another story in the backlog for something more robust later.

Finally, the conversation led us to realize that there might be some additional work around selecting which switch to manage as well as supporting multiple models and manufacturers. This functionality has been moved to other stories in order to provide a more manageable scope for the read and edit stories.

A Different Way to Look at Value

It is very common for teams to become accustomed to looking at value as a full feature that you can package up and sell to a customer - complete and production-ready. While not unreasonable (and not always wrong), this mindset can sometimes make it difficult to break down these kinds of stories. 

If we look at the Agile Manifesto, we don’t see any references to terms like “production-ready” or “sellable”. Instead, we see terms like “working software” and “collaboration”. So when we look for a story to have value, we want to see that we’ve created working, functional software and that it helps us collaborate with our customers and users and helps us learn something about the software we’re creating.

If we look at our groupings above, we can see that none produce documentation, mock-ups, or processes as their deliverable. For example, if we took on the update story first, we would have a simple interface that actually updates the VLAN on a given switch. This doesn’t solve the whole problem, but it lets us put real software in front of the users to see how they use it. In doing so, we may find that the user wants to see what VLANs are already trunked to the switch to select from. This not only tells us that we need an enhancement to the work already done, but it may also influence how we collect and store information from the switch in our “read” story.

Conclusion

Through this process, we’ve turned one large, complex story into five much more manageable stories:

• As a technician, I’d like to see the current switch VLAN configuration.
• As a technician, I’d like to be able to save new VLAN configurations from a web interface.
• As a technician, I’d like to be able to select which switch I am managing.
• As a technician, I’d like to be able to manage multiple switch manufacturers and models.
• As a technician, I’d like any automated changes to be validated with robust testing. 

All of these produce valuable, working software that help us collaborate with our customer. They are now ready to be prioritized in the backlog and worked through just as any other user story.