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

Meet us at Agile People Sweden 2018

Come and join the coaching clinic with agile42 at Agile People Sweden 2018 Conference in Stockholm

Image of sofia.svanback

Sofia Svanbäck

I am the Business Relationship Manager of agile42 in Finland and Sweden. I started working at agile42 in May 2018 and haven’t done anything so interesting before. The decision to join agile42 is a decision I am proud of today. My days are filled with customer related things, like negotiations, offers, and training / coaching bookings to mention a few.

Meet The Coach: Sunny Dhillon

For our Meet The Coach series, agile42 coach Sunny Dhillon talks about his background, his agile journey,  and insights about Agile adoption. 

Image of agile42

agile42

News and views from the Headquarter of the agile42 team

A word from our coaches

In this video our coaches explain why they have chosen to work with agile42 and the company culture that the team has established

Image of marion

Marion Eickmann

I am one of the founders and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

How we facilitated an all-hands retrospective for 60 people in three hours

Imagine a retrospective that is attended by multiple teams, such as those of an entire program, or even organization. What would it look like?

Image of lklose

Lukas Klose

My first time at the agile42 Innovation Sprint

A look at the agile42 Innovation Sprint that took place in Thailand in July 2018

Image of sofia.svanback

Sofia Svanbäck

I am the Business Relationship Manager of agile42 in Finland and Sweden. I started working at agile42 in May 2018 and haven’t done anything so interesting before. The decision to join agile42 is a decision I am proud of today. My days are filled with customer related things, like negotiations, offers, and training / coaching bookings to mention a few.