“Honey, I shrunk the backlog” – Rebuilding agile processes
The backlog is a great idea… until it isn’t.
Many successful teams deliver backlog items every day, but their backlogs aren't getting any smaller. Delivery success is overshadowed by the never-ending backlog.
When looking at product backlogs (not sprint backlogs)!, it is rarely ever the case that the backlog will be complete over the expected time allocated. Unfortunately, more often than not, it keeps growing and becomes unmanageable – which is quite an understatement.
Product discovery, dual-track agile, OKRs and so on make it worse by accelerating backlog growth without taking any of the rotting items away. Worst of all, doing the backlog distracts from delivering benefits to the customers and responding to change.
So, what’s the solution?
In his latest Lithe Talk, Allan "Nuke the backlog" Kelly suggests we rethink the very idea of the backlog and rebuild agile processes around outcomes.
Many product managers might raise their eyebrows at this suggestion.
We should do everything in the backlog, shouldn’t we?
But, as Allan says: “the road to hell is paved with good intentions” – and these intentions can mislead us.
The Backlog Challenge
Product owners will always be faced with stakeholders, customers and users who will come along and suggest new features and ideas and these ideas get added to the backlog, sometimes quite simply to avoid the bigger and more challenging conversation of saying “No.” But inevitably, these backlog items fight to break through other priorities and when the key stakeholders wonder where the features are, well… they’re in the backlog.
This lack of prioritisation and marooned backlog items leads to a corroding of trust.
This doesn’t really abide by the agile values that product managers place their trust in; agile values are all about openness, trust and honesty, and when we keep putting items in the backlog without any intention of ever getting around to them, this not only impacts customers but also our teams.
Our teams are like sponges – they will absorb all the processes and expectations we have of them, and when the backlog continuously gets delayed and timelines slip, the impact on teams is significant in terms of their relationship with the backlog.
Many argue that product owners need to drive more innovation. Allan argues that our problem isn’t having enough ideas for the backlog.
Our problems are:
Delivering the backlog
Meeting the backlog expectations
Backlogs don’t have the ability to scale – they work well within smaller timeframes, but when the backlog is full to the brim with items, the timescales can get lost in the noise.
Organisations need to rethink the mechanism for backlogs and evaluate how much importance they give to the backlog.
We know that there is a vision in there somewhere but between this myriad of backlog items and pressure to ‘beat the backlog’ assigning KPIs and success metrics to the backlog can be detrimental as we may never really see success.
Tracking Backlog Metrics
Here are a few key ways that product owners and scrum masters can evaluate the objectives they have in place for their backlogs:
What is your team’s velocity? How fast is your team completing backlog items?
What is your backlog growth rate? What is the % of average growth within the backlog?
Having an idea of these statistics can help product owners forecast future dates of when certain items can be completed, otherwise, it can lead to a situation where there is no data and no end in sight.
Backlogs can become a bottomless pit and that is something we need to avoid to have a chance of ever achieving our goals.
These metrics are particularly important in digital terms because it is very easy to keep adding cards into JIRA (and other software) and the numbers start to become meaningless.
Objectives and Key Results & The Backlog
What comes first?
The Backlog or Objectives and Key Results?
Objectives and Key Results are Allan Kelly’s pet subject.
How do you integrate Objectives and Key Results (OKRs) in a situation where the backlog is full to the brim?
One of the key questions that Allan encourages us to think about is:
Are your OKRs derived from and reflect the backlog?
Or
Are your backlogs built to deliver OKRs?
Organisations need to reflect on whether they are crystal ball gazing into their backlog and thinking about the work they want to do in the next few months and then basing OKRs to describe that work, or are they setting OKRs based on business strategy, business priorities, overall goals and objectives?
“If items aren’t in the backlog and we are using OKRs around what is within the backlog, OKRs then become another mechanism to keep adding stuff into the backlog. Which is counterintuitive to what we are trying to achieve as adaptive and agile organisations.”
Imagine this: What would you do if you lost your backlog?
A hack. A software error. A zombie apocalypse (okay, maybe not this one) and your entire backlog is gone. Zilch. Nothing to see here.
This wouldn’t be a problem immediately.
Many Product Teams would know what their immediate priorities are and would be able to work towards them.
But the longer you go on without a visible backlog, the greater the opportunity to focus on what the real priorities are. Many would find it liberating to start fresh and think about the key objectives they are trying to achieve.
“NUKE THE BACKLOG!”
If you lose your backlog, don’t worry.
You have nothing to lose, but your burndown charts and burndown charts are predicated on the assumption that doing the backlog is the right thing to do.
And that's not necessarily the case.
If we think about it, backlogs by definition contain some high-value items as well as low-value items. And if we do all the high-value items, then a legitimate question is: should we be doing the low-value items?
If we accept that we aren’t going to do the low-value items, that using burndown charts and getting to zero is what we need to do, then we immediately realise it's not a good measurement of success.
Life without a product backlog – what does it look like?
Let’s take a look at Amazon.
Jeff Bezos has long promoted a ‘Day 1 Mentality’ at Amazon – the idea being that every day at Amazon should be like the first day of a new startup.
This doesn’t by any means suggest that Amazon teams don’t use backlogs, but what it does suggest is that with the ‘Day 1 Mentality’, this ‘start-up’ has more resources, logistics and operations as the years go by but the basics remain the same.
What are we selling to our customers?
What do our customers want and need?
What will our customers exchange for money here?
What do our users and customers want from us?
Taking this customer-centric view is the baseline for the ‘Day 1 Mentality’ that Jeff Bezos advocates for. By putting the customer first, if a project is half done or money has been sucked into one that isn’t serving the customer – it is okay to move past it and not continue with it.
Be driven by the customer and what the customer sees as value.
This way we are not just drawing out a backlog but instead focusing on what customers want.
Purpose and Mission: becoming outcome-oriented
Our companies exist for a purpose: to benefit society.
Our organisations have Level 1 goals – these are the reasons why the company exists.
Then come our missions (Level 2 goals), which could be a single focused mission or multiple missions which our teams exist to deliver on. These are the things that keep the company going.
Every three months, we should look at our Level 3 goals (our backlogs) and reset them, meaning that we throw away any backlog we’ve got and align ourselves with our objectives. There can be many mechanisms that can be used for this approach, such as, OKRs, Product Goals and outcome-oriented thinking.
Working in this manner, allows organisations to wipe the slate clean and rethink what it is that they’re really trying to achieve.
The process?
Reset every 3 months
Nuke the backlog
Re-assert missions
Start again, think Day 1
Then decide:
Desired outcomes
Goals/Product goals
OKRs (Objectives and Key Results)
And then, write them down.
Allan encourages organisations to choose their mechanism when it comes to resetting.
Just-in-Time Story Generator
When nuking the backlog, replace the backlog with a Just-in-Time story generator.
In this machine, things go such as: your purpose, your mission, your OKRs, your product goals, jobs to be done and whatever technique the organisation is using.
These fall into the story generator and every time a team needs to decide what to work on, they look at the story generator and move forward towards goals and missions.
Organisations can define their context with:
Purpose
Mission
Day 1 Thinking
OKRs
Product Goals
Jobs to be done
True North
This filters into a machine that helps them create stories that advance them towards their goals.
The aim is not to stockpile stories and these stories that are generated are those that we need and not ones that last for months on end.
When executing this, it is important to add reviews that assess what the teams need to see in order to move forward with their goals. Have they been able to deliver the benefit and added value for the customer?
Wide-Narrow-Wide
When setting goals and aims, it is common to go through these phases:
Wide expansive thinking when setting goals
Narrow focus when executing against goals (this is where the majority of time is spent)
Wide broad thinking when measuring results
Consider this as a super cycle of sprints. The sprints don’t change but the User Stories are fresh.
Every few weeks, teams reset and use the User Story-generating machine and use sprints to get closer to the finish line and reset again.
Work within Timeboxes
Ask not: How long will it take?
Ask: What can we do in the time we have?
Allan’s advice is to try to live more in the moment without endless preplanning and try to complete the items within the time that we have. This is caveated by the fact that there are quality control processes built into those timelines so that these don’t end up extending our super cycle of sprints.
Lead with Goals
In order to move away from backlog mechanisms, we need to lead with our goals.
If our work follows goals, our goals will follow strategy and our missions and our purpose. Too often in our backlog-driven development, our backlogs are at the fore and our backlogs are leading our work and because the backlogs are leading our work, we lose sight of the bigger picture.
Backlogs bog us down and are not goal or objective driven.
Allan refers to this way of thinking as Objective Driven Agile (ODA)
We put our objectives first and we work backwards and assess what we can do to advance against our objectives in the time that we have.
With ODA (Objective Driven Agile), we can drop a lot of the unnecessary processes that lead to burning a lot of time.
About Allan Kelly
Was once upon a time a frustrated software developer, set out to make life better for people like me.
Today Allan helps companies create environments where digital professionals can thrive and do great work to enhance digital agility and create competitive advantage.
In agile Allan found a set of ideas, techniques and people which matched his own thinking and to which I could contribute.
That desire to change the world has led him to write seven books - his latest is "Succeeding with OKRs in Agile". The ones he’s most proud of are "Business Patterns for Software Developers" and "Continuous Digital."
In addition, Allan has pioneered techniques such as Value Poker, Time-Value Profiles and Retrospective Dialogue Sheets.
Always open for discussion, Allan engages through consultancy (part or full time), training and discussion.