April 8, 2015

Techniques for Breaking Down Technically Complex User Stories

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 post will explor...

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.

 

Image of daniellynn

Daniel Lynn

Agile Coach
blog comments powered by Disqus
Image of daniellynn

Daniel Lynn

Agile Coach

Latest Posts

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.