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

Presenting at ScanAgile 2019

Cliff Hazell and Pascal Papathemelis will be on stage at the annual ScanAgile conference in Helsinki on March 13th-14th

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

How to plan and create a structured approach to coaching?

To see tangible results in your team’s performance, you need a way to structure your coaching.

Image of sdhillon

Sunny Dhillon

Basic Desires and coaching

Notes from the Agile Finland Coaching Circle of January 2019

Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.

From Agile to agility: Andrea Tomasini and Dave Snowden keynote at Agile Beyond IT

Andrea Tomasini and Dave Snowden presenting at "Agile Beyond IT" in Berlin on 13 March 2019

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.

agile42 is offering Scrum trainings in USA - Which Scrum course is right for you?

Are you looking for Scrum trainings in the U.S.? Read on to find out which course is right for you. 

Image of asanders

Aaron Sanders

Image of agile42

agile42

News and views from the Headquarter of the agile42 team