Scrum Master toolkit; Breaking down work

One of the most vital skills a Scrum Master should develop and impart to others is the ability to break down work.

This means taking a big idea, feature or piece of work, and turning into into smaller, vertically sliced and customer value focused items that can be delivered inside a sprint.

Not just tasks or functional bits of code, but actual working product increments that can be inspected with the customer to get feedback and adjust the product backlog.

It’s not uncommon for teams to struggle with this problem. It’s often very different to how they’ve traditionally worked, and takes a complete change to the way we approach building products.

Scrum Masters are often going to be the people in a Scrum team with the most experience and knowledge in work breakdown practices. It’s not enough that they have tools, they also need to impart their knowledge so the team can become cross-functional and self-organizing.

So this article intends to share my personal approach to helping teams improve their work breakdown practices; Not just how to do it, but how as a Scrum Master you can take your teams on the journey of acquiring and developing the skill for themselves.

This means working through a few stages;

Creating a desire for change
Teaching theory
Coaching the practice
Removing impediments to growth

Keep in mind, that this is my personal approach that I’ve used with many teams. That doesn’t make it the ‘right’ approach, just one I believe can help you step toward the desired outcome. Take everything here with a grain of salt, and adjust as you see fit.

1. Creating a desire for change

One of the most important elements of creating sustainable long term change is ensuring that the need for change is understood, and the people most responsible for it’s success long term genuinely understand the ‘why’ behind our actions.

This is the first hurdle I’ve seen many Scrum Masters stumble on.

It’s very tempting to join a team, and immediately recognize a pattern or potential improvement opportunity and want to jump in and make a difference. Work breakdown practices are often the most visible.

How many of us as Scrum Masters have joined a team, looked at the ‘user stories’ in Jira and thought “Wow, these are just requirements documents?”

When you see ‘user stories’ that aren’t user centric, contain dozens of requirements or detailed technical specifications, it can be very tempting to immediately start lecturing the team (Perhaps we prefer the term influence) about the importance of customer value focus, of vertical slices, etc. etc.

I’ve seen first hand how this can backfire. Defensiveness is the first reaction. Someone in the team probably created these user stories. They’re probably doing exactly what they thought was right (perhaps even what someone else has told them to do), and they know we’ve been getting stuff done, so who are you tell us we’re doing it wrong?

So without even realizing it, we’ve predisposed some in the team to close their mind to a different way.

In order to solve this problem, you must first start with a real root issue that the team can agree needs to be addressed.

Pay attention during Scrum events. Is the team actually finishing work they pull into sprint? Are they consistently achieving sprint goals? Are they getting feedback from customers at sprint review?

If everything appears to be running smoothly, then it’s hard to argue for a significant change in the way we work. Chances are though, that some of these things are problematic. If not, there’s likely a transparency issue that needs to first be addressed.

Once we have identified some consistent problems, now we can tie this to our need for change. Let’s say the team is struggling to deliver sprint goals;

As a coach, you can offer the possibility that the work is being broken down in a way that makes it harder for us to deliver in the time frame. Is the team aware of the theory of user stories, or techniques like story mapping?

The goal is not to push, but to offer potential solutions for a problem they can all see.

In almost all cases, I’ve found most teams are willing to try something.

“I’d be happy to run a workshop next sprint for half a day, and see if we can’t find a better way of breaking down work”.

All you need is buy in for some time to talk about theory, away from the ‘real’ work (and all it’s baggage). We’re not trying to change the world yet, just explore other options.

When this agreement is in place, we can move on to part 2.

2. Teaching the Theory

There’s a good reason I personally separate two distinct steps; theory and practice.

My experience tells me that trying to teach a new way of working by using our existing work tends to pull in all sorts of assumptions and personal connections.

An attempt to say ‘this way is better’ when we’re looking at work that people have already invested their time into will be met with much more skepticism than when using unrelated, theoretical examples.

That’s why the first workshop I run deliberately uses a made up company, a made up product, and made up features.

Essentially, this second step is all about introducing the theory behind user stories, story mapping, and some other breakdown tools, in a way that cannot yet be turned into ‘but that won’t work in OUR domain’.

Once we have buy-in that the practice might work in theory, then, and only then will we move on to applying it to our actual product backlog items.

So, how do you structure a workshop to teach this theory effectively?

I just so happen to have such a half day workshop, and I'll share some of it’s high level structure here.

I always start with a question;

A map of Middle Earth. Definitely fits into any Agile workshop

Why did Frodo Baggins travel to Mordor?

“To destroy the One Ring!” someone will inevitably call out.
Isn’t it cool that almost anywhere you go, you can ask this question and at least a few people know the answer?

Tolkien wrote a great story, and we all know it. Do you think If he had just published this detailed map, and maybe some instructions with the melting point of magic rings, that it would have been enough to motivate Frodo to take his perilous journey?

Do you think that would have been enough for all of us to remember it?

You see, a workshop about breaking down work for me always has to start with the power of stories. How detailed documents and data will never do as much for helping us understand something as a good story.

The first part of this workshop is really just about the concepts of building shared understanding through ongoing conversation, and the format and structure of user stories.

As an inhabitant of middle earth
I want the One Ring Destroyed
So that Sauron can’t enslave the free-peoples

We can teach things like the relationship between features, user stories and tasks, the who/what/why format and the value of acceptance criteria.

But as with any workshop, hands-on is the best way to learn;

The first major exercise in a work breakdown workshop, writing user stories

The idea here is to have some prepared features for some fictional business. I use a book store with example features like:

Feature Name: Browse Books

Summary:

This feature Allows users to browse the book collection

Acceptance Criteria:

•Users can search books

•Users can Browse by category

•Users can sort by category

•Users can see top sellers and recommendations

The exact format here doesn’t matter too much, but just ensure there are a few high level ‘features’ (i.e, some potential work that’s customer-centric and far too big to be likely built in it’s entirety in a single sprint). All the features should be for the same product and part of a somewhat linked user flow in order to support a later part of the session.

Then you can break your workshop into groups and have them practice writing some user stories in the correct format, with acceptance criteria.

Give them enough time to come up with a decent few stories, but not enough time that they feel like they are ‘done’.

Make sure to have groups share back and discuss.

Phase 2 of the workshop is all about breaking down user stories into smaller pieces.

We’ll teach some theory about INVEST and SPIDR:

Credit to Mike Cohn for the SPIDR method

And once again we’ll teach them by doing;

Now the activity is to take the (inevitably) large user stories from the first activity, and break them down into smaller user stories.

Once they’ve done this and shared back, Phase 3 of the workshop focusses on Story mapping.

So it’s time for some more theory;

Credit to Jeff Patton for the approach and Planio for the image

We can teach some Story Mapping theory and have the team create a framework for a story map.

The fun part here is that our features themselves can be revealed to have been part of a user flow.

Now we can add all our previously created features to this story map, combining the user stories written by the groups in earlier stages into a single flow.

Perhaps there are deliberately some empty features that weren’t covered in phase 1, but either way we will likely end up with an incomplete story map with some glaring holes.

This is a great way to teach the value of a story map for uncovering potential user value and opportunities to break down work.

This nicely leads to the last big activity, which is to write some more user stories to fill out the story map and then draw an MVP line.

The groups have now gone through a fairly complete process that they can apply to real work in future, which brings us nicely to the next step;

Coaching the Practice

So by now, groups have seen and practiced some theory. We should have a reasonable amount of buy-in to try this for real.

This next step is really just about repeating the workshop, but in a more relaxed format and with real work.

Have the team identify some upcoming piece of work that we’re highly likely pick up. If we have a Product Owner, we could work with them to articulate it as a feature (or a series of features) in a similar format as our workshop features. (Don’t overengineer these, the team will contribute most of the thought)

Then we can simply facilitate a session with the team to do something like the workshop; create some user stories, put them on a story map, and then continue to break them down until most are sprintable.

The primary goal of you as a coach here is to have the team take the lead on the approach and timing of the session. You want them to come away feeling confident that this is something they can do without you.

So remind them of the process and options, but never tell them what they should do. Just keep asking ‘what could we do next?’.

Within a few hours, I’ve seen most teams go from a large, vague backlog item that might have consumed days of analysis to a fairly complete story map that can be captured and iterated over the coming weeks and months.

Encourage the team to keep the story map, and to revisit it for refinement and even Sprint Planning and Review. This might even become the standard format for a product backlog if the team is highly focused.

Now we’re ready for the final step;

Removing impediments to growth

In order for this new approach to stick, the team will likely need support and encouragement to think about it regularly. They will likely be asked by stakeholders for documents and plans that are in more traditional formats, so you as a Scrum Master might consider helping stakeholders to understand the benefit of story mapping to manage a backlog, and how they can best interact with it and the team.

They may still have stakeholders that want to hand over complex requirements documents or specific descriptions of a solution, rather than a Story that provides a problem for the team to solve.

You may also consider working with the Product Owner to teach similar considerations when dealing with customers.

Most importantly though, continue supporting the team to practice these methods as often as possible. Whenever some new potential work comes up, offer to help with a workshop to create a story map, and as before, coach them toward self management.

When they struggle to break down work, remind them of INVEST and SPIDR, and how to look for gaps in a story map and think about the user flow.

Before too long, you’ll almost certainly find the team begins taking the initiative and running these sessions without you.

One of my fondest coaching memories is a big room planning event with a team I’d just coached this way. A new piece of work was brought to them at the last minute, and without a word from me, they moved to a wall and started creating a story map.

So the final step, and it’s final lesson, is that Scrum Masters exist to create empowered, self-managing teams.

It’s not enough to simply teach teams a method, but to instill in them a desire to work in a more effective way. For this to survive long term, we must relentlessly remove impediments to success.