How Work Breakdown Structure is Killing Your Agility

So, you work in JIRA during the Sprint Planning or Backlog Grooming session and go through the next user story to determine what needs to be completed to meet the requirements. And immediately, it’s clear that the goal of the user story touches a lot of different components. The reaction – we need to create additional JIRA issues to encompass the changes that need to be made in all the areas.

Here we go:

• Update the Database
• Implement new API on the Backend
• Update the Front End
• Integration Test
• QA Review

Because encompassing and doing all these changes in a single Story is hard to track inside of a single story on the JIRA backlog, your Team naturally opts for a pattern to create new Issues with slightly different title prefixes. Backlog then expands to have stories with prefixes like [FE] to indicate Front End, [BE] to indicate Backend and etc. 

In the end, your Sprint Backlog increases to consist of all work that was necessary to complete a single feature or a single piece of user value.The Agile Board lists all of the stories and the team is ready to start.

Does this practice sound familiar to you? Well, while somewhat logical, what you have created is a Work Based Stream Anti-Pattern. Read on to learn more of what it is and why it is bad, and how to fix it. 

Work Based Stream vs Value Based Stream

Work Based Streams are good when working on repetitive well known tasks where work based items are part of your inventory. An example – let’s manufacture X chairs, X cabinets, and X tables and sell dining room sets. Now as a chair, cabinet or table is made, value is created. And, when a chair, cabinet, or table are combined into a set, the value multiplies.

The problem with Work Based Stream in engineering however, is not that it’s not a good way to organize work. The issue is that the work is organized around the wrong goals. When a single developer completes an individual Work Item, if this work doesn’t create user value – it simply doesn’t matter. “Never mistake activity for achievement”, as was said by John Wooden.

Now let’s be clear here, this pattern does not immediately violate Agile principles. The team may be very agile of implementing features ( meaning change direction quickly and with ease ), making decisions from product perspective, etc. However, Team’s performance over time with the use of his practice will degrade, causing ripple effects in the ability to get things done. Imagine an engine in the car is running perfectly great, well, if we add sand with the oil – it will still work degrading its performance over time and eventually leading to a big halt.

Let’s imagine a backend improvement made to refactor the way a certain button performs into a function so it can be reused across the application. That may be great. But it doesn’t help any users. So the value of this work is not created upon the work completion. The value is created when someone leverages the new function to add more user value.

Work Based Streams are based on work – and work produces outputs. Value Based Streams are based on value – which drives outcomes!

What is Work Based Stream Anti-Pattern?

The challenge in breaking down work into micro stories, for example as a popular way of managing work in JIRA, the Team often loses focus on the dependencies of these Stories. Someone has to keep track of all related Stories and monitor them for completion, who or what is next, and coordinate testing and releases when everything is done. This creates a lot of micromanagement.

Often, it seem like Teams are delivering value, however they aren’t. They are only completing work, as the value is only created when all of the stories are completed. And, if anything gets carried over into following Sprints, the discipline to manage the work that needs to be completed is often disrupted. New Goals take precedence over leftover work and increase Work in Progress causing things to get stuck. 

If you’re managing a Work Based stream, tracking of work done creates an erroneous picture of high performance. “Look how many things we’re getting done! Look how many stories we completed!” Unfortunately these metrics do not tell the truth. Celebrating work done outside of generating value – does not move the needle. 

There are many problems that occur in a Work Based Stream Anti-Pattern. However, people fail to diagnose the real issue and instead attempt to cure the symptoms, which is not correct. The correct way to fix things is to get to the root of the problem.

If you’re seeing one the symptoms below, the cause may be the Work Based Stream.

1. Features marked as “Done” are never really done. There is always something remaining to do and the remaining efforts seem not being naturally accounted for because the original story is marked as “Done”. 
2. The backlog is riddled with lots of very technical user stories that nobody except for a few Team members may understand and the Team loses interest in them because “it doesn’t concern me”.
3. Team gets large throughput of completed work and celebrates meeting and even exceeding Velocity, but ultimately no value is created.
4. Team members are concerned with getting their Work Item done as individual contributors over how their completed work fits into the bigger picture of delivering value.
5. Single Developer works on all related feature items in sequence and no other Team Members pick up issues that go together. 
6. Features are marked as Done, but after completion have a high number of Bugs as separate backlog issues. The bugs then fall through the priority and do not get worked on because they are lower priority, instead of understanding that the bugs are an indicator that the Story, despite its “Done” status has not been completed.
7. Lastly, Sprint Carryovers are often attributed to the Work Item Steam Anti-Pattern because there is a missed opportunity to swarm the Team to get the entire piece of value done together as a Team in a quick succession.

How do you fix Work Based Streams?

The answer is to create a Value Based Stream. Value Based Stream is grouping of all work that pertains to delivering User Value into one item of work, so that when all the grouped work is done, the value is realized. Of course, this will impact the metrics, how the Team will forecast the amount of work they are targeting to complete, and how the Team’s progress will be displayed. But it’s not a difficult adjustment compared to the benefit of placing the focus on value.

Value Based Stream can be instrumented in multiple ways. First group all of the stories that relate to a piece of value together. This can be done via an Epic. However, then it’s important to focus on getting the the entire Value Based Stream completed as soon as possible to realize the value and not celebrate the vanity metric of the percentage of Epic’s “doneness”.

Another way is to extensively use Tasks and break down all work that is part of the user Story into related Tasks. Frankly, Task breakdown and Epics are very awkward in JIRA – its hard to tell the Story progress without digging in and lots of time is spent looking for the information. If that sounds familiar to you and is a point of frustration, you may want to consider looking at a simpler alternative solution that’s purposefully built to promote proper Team behaviors, discipline, and culture. 

Lastly, once everything is broken down into Tasks, here comes the hard part – how to swarm the entire Team to complete the work in the most efficient way, one priority item at a time. But, that’s a topic for another day. Thanks for reading and stay tuned for more!