Share this
by Ray Cooke on 11 November 2015
The agile backlog is now a pretty ubiquitous feature of development projects. We know and understand how important it is to prioritise it by business value and we look to the Product Owner to make these critical decisions for us. After all, they are in a position to understand what work needs to be done to best meet our business needs, which obviously also encompasses our user and stakeholder needs.
The #1 reason for agile project failure
In my experience the majority of Product Owners still find prioritising and making decisions relating to the agile backlog very hard. This is unsurprising given it's a very difficult problem generally requiring a lot of domain knowledge, expertise and a very good understanding of the market and users for which the product is being built.
This is not necessarily just a Product Owner problem however. What the Product Owner should not require is technical understanding. The delivery team, which tends to include a ScrumMaster, testers, developers and business analysts in various flavours should be doing more to help the Product Owner out in this area.
Specifically I'm talking about work breakdown, the process of getting from that initial high-level business goal down to the individual user stories and requirements that compose the backlog. This is supposed to be a joint process undertaken between the delivery team members and the Product Owner but sadly, in my experience, neither tend to be very good at it.
"The number one reason for agile project failure is the inability of the project team to appropriately breakdown the work"
I like and agree with Jurgen Appelo's LinkedIn post, which frustratingly I now can't find, about his irritation with articles that give you "the top 5" or tell you the "#1 thing to do to guarantee...", however, there has to be an exception that makes the rule and this is mine.
I personally believe that the number one reason for agile project failure is the inability of the delivery team to appropriately breakdown the work to be delivered. I cannot emphasise enough how important this is, how many times I've seen it being done badly and how much pain I've seen it cause.
7 symptoms of a bad agile backlog
When done badly, the symptoms are various and include:
- Lengthening time between product releases and therefore widening feedback loops
- Large chunks of the backlog having the "same priority" and disinterest from the business to prioritise any further
- A large number of "technical stories" (stories that are there for technical reasons and don’t represent an addition in business value to the product) on the backlog
- Lots of technical dependencies between stories making it impossible to prioritise between them. This, as we'll come to later, means they're not independent and therefore the user stories are not conforming to Bill Wake's INVEST model (independent, negotiable, valuable, estimable, small, and testable)
- Someone outside of the project team finding it hard to understand the backlog, even if they have domain knowledge
- Large amounts of rework happening as a result of requirements clarification and misunderstandings
- Delivery paralysis, extended feedback loops and business level testing to the point where the delivery process could at best be described as Water-Scrum-fall.
The reasons that bad agile backlog breakdown occurs
Most individuals I discuss this with can talk the talk. I hear phrases like "vertical slices" and "minimum viable product", but this doesn't seem to translate to walking the walk and I can understand why.
I am a technically minded individual. I started my professional life as an electronic engineer, moved on to become a software developer, technical lead, team lead and then onto managing IT teams and groups. In my previous post The problem with optimising the software development process I talked about one problematic tendency I had discovered of myself that I directly attributed to being a technically minded person. This is another area that I struggle with that I attribute to the same training and technical mindedness.
Whenever someone asks me to build something I start breaking it down mentally. Because I've been technically trained I effectively start drawing component and class diagrams in my head. I'm naturally breaking down a problem at a system or component level. This seems to be a common trait of most technical people.
Since a software delivery team is composed primarily of technical people, an undesirable behaviour is exhibited. Rather than ask a Product Owner to break down a story from a business or user stand point, a technical team will more naturally offer up "sub-stories" which are technically interdependent deliverables that will together deliver on the story. This can very quickly become the norm and there comes a point very early on where the task of prioritising the backlog becomes impossible for the Product Owner to do because of all the technical dependencies.
After this the problem snowballs because the Product Owner starts to lose interest in the detail, becoming less and less involved in the day-to-day delivery process.
How to break down work the right way
As a member of an agile deliver team
I want to be able to break down work the right way
so that my project isn't a disaster!
Okay, so now we can see why bad work breakdown might easily occur and we can identify the symptoms of it already happening, but how do we break down work the right way in the first place, or, more challengingly, how do we correct a backlog that's already been broken down the wrong way now that we can see the problems we have with it?
Thankfully a lot of help already exists out there on the web once you know what to look for. A great starting point is the INVEST model for user stories which first appeared in an article by Bill Wake in the early days of the eXtreme Programming method. As briefly referenced above using the INVEST model we say that the good user stories are independent, negotiable, valuable, estimable, small, and testable.
Simply assessing existing items on the backlog against the criteria in the INVEST model should highlight the ones that need attention. Don't be alarmed if it's the vast majority, that's not unusual and if it's not the majority you're better than average already! Once you’ve identified them though it helps to have some guidelines for breaking them down in a way that helps all the smaller stories still conform to the INVEST model.
I often use this article Patterns for splitting user stories by Richard Lawrence. These patterns are generally reasonably easy to apply. Richard has also very helpfully provided a workflow, which can be very useful for structuring the process.
The workflow also helps with the problem of fixing existing backlogs. You just keep applying that first workflow step until you're in a position where your high level story meets the INVEST criteria and go from there. Once you have fixed that one, you can move on to the remainder of the backlog.
Warning signs to look out for in the breakdown process
Even with the patterns and the workflow it can sometimes be hard to get out of the technical mindset. Symptoms of this that I come across a lot are:
- The technical team telling the Product Owner that it's not technically possible to break the work down any further
- Hugely front-loaded work to get the "architecture" in place to support the first story
- A general focus on technical dependencies and limitations when discussing story breakdown.
How to make it easier for the technically minded
When I find myself or my team getting stuck on a technical solution rather than thinking at the business level I've found Gojko Adzic's Hamburger Method is a good tool to bring out. I haven't yet tried it with architects but I'm optimistic it will work there too.
The short summary is that you allow the delivery team to come up with technical options for each of the areas in the story, visualise them, size them in complexity, reorder them and then let the Product Owner take a "bite of the burger" as an end-to-end story. It's relatively simple to do, visually appealing and engaging and, most importantly, keeps the conversation moving in the right direction at a possible impasse. As Gojko says in his article though, don't do this when the team is hungry!
Tl;dr: In summary
The biggest cause of agile project failure in my experience is the inability of teams and product owners to break down the work for an agile backlog in a business meaningful way. This sets the project up for disaster from the outset.
It's easy to end up here by accident and technically minded individuals are more prone to this than others, which puts software development projects at pretty high risk of it going wrong.
I've listed a few ways of spotting when this has happened and provided a couple of ways of correcting it. It doesn't have to be a project life changing event in effort terms, though it can be project lifesaving!
Pay attention to the INVEST model and use the work breakdown patterns and workflow. Use the "User Story Hamburger" to help the technically minded get out of a rut.
Practice makes perfect and discipline from the delivery team and the product owner is key.
If you've found this post useful. Let me know how it goes for you in the comments or click the social media buttons at the top so that I know this is what you're looking for and I'll keep writing!
Thanks for reading and good luck!
Ray Cooke is a Development Manager and a Lean & Agile Business Transformation Coach, based in Equinox IT's Wellington office.
