A Fresh Backlog!

An Observation

As I was walking through a local grocery store the other day, looking to buy some berries and bananas, I was struck by a thought.   To ensure their customers have a selection of edible, tasty products, stores and farmers markets ensure that only the best and freshest products are on display.  They are continually rotating stock removing any items that won’t appeal to customers because of how they look or perhaps even smell.   If they didn’t, and you routinely found moldy, rotten and smelly fruits and produce, you’d likely shop elsewhere.

As I was pondering that, it occurred to me that your customers, who use your products and services, should be able to expect the same attention to their needs – a steady stream of the freshest, most valuable new functionality.

Agile or Agility?

Before we get started, let’s do a quick review to ensure we have the same understanding of what I mean when I say Agile, or more importantly, agility.   Agility is the ability to adapt at speed as soon as you realize that change is needed, for little to no additional cost.   That last bit, at little to no additional cost, is important and we’ll get to that in a few of the examples.

We’re all likely very familiar with the concept of a Product Backlog at the team level.   Depending upon your organization you may also even have Program and Portfolio backlogs.  This is where we collect future work, ideas that we have that we hope will be useful and valuable to our customers. 

If you’re using Scrum or another iterative delivery practice, your iteration Reviews should be providing you with much of your near term future backlog items based on feedback of the recently completed efforts.   If you are using Scrum and your Sprint Reviews are not providing feedback that informs your next work, or changes to the current product, you’re probably just doing a demo or otherwise going through the motions of the review itself.   Your customers should be providing you feedback early and often which helps build your backlog.

Maximize Value, Not Volume

I’ve encountered many Scrum teams that have enormous backlogs, 300 stories and more, some of which have been there for more than a year or even two.  Refinement sessions with these teams becomes an exercise in finding a needle in the haystack when the Product Owner says “I know I already have a story for this”.   Often 5 to 10 minutes, for the entire team per planning session, is wasted just trying to figure out if a new story is a duplicate, or even triplicate.   Over time, and multiple teams, this amounts to a very large “hidden cost” that the organization is paying just to service this dysfunction.   Think of it this way, if your grocery store mixed in the fresh fruit with the rotten, moldy fruit how would you feel about it?   Would you dig through the layers of fruit to find the few valuable pieces?   No, you’d shop elsewhere.

If you’re using SAFe, someone likely far above your position has already made the decision to limit your group’s agility to 4 major “inspection points” per year, or once per Increment Review which is typically every 6 iterations, or 12 weeks.   What typically happens is that, every 3 months, the ART will have a multi-day Program Increment Planning event which includes everyone on all teams, all the stakeholders, all the management, and likely some folks from other ARTs who either depend on work your group is doing or is planning on dumping some of their work on you – these are known as “external dependencies”.   Groups will spend these days planning the work, often in incredible detail, for all of the teams for the next 3 months.   All too often this also includes re-planning work that wasn’t completed in the current Increment.

The teams will have spent weeks decomposing Features, from the Program Backlog, into user stories in preparation for this event.   This implies that teams are refining work months in advance of when they expect to actually do the work.   You’re likely talking hundreds of hours, spread across quite a few people, spent refining Features and stories across the ART to prepare for future Increments and Iterations. 

If at this point you detect a need to change direction that is a huge amount of time and money wasted in order to adapt quickly.   Remember what I mentioned earlier, we want to adapt at speed for little to no additional cost.   Because of all the time and money spent refining multiple backlogs to this point, most organizations will stick to the plan rather than changing direction at speed due to what is known as the “sunken cost fallacy”.  That belief is that since we already spent all that time and money to create and refine this work, we might as well not let it go to waste and do it.   

Only you can determine if the cost of delay of not pivoting, or adapting at speed, is worth it to you to jettison the pre-work that has been done to this point.   But don’t let those “sunk costs” sway you inordinately – examine the value of doing the old work versus quickly moving on to the newest opportunity or changing markets.   And of course inspect and adapt your processes so you don’t get stuck in this situation again – you’ve been presented the perfect learning opportunity – don’t let it slip away!

Some Tips:

So now that you understand some of the issues with having backlogs that are too large or keeping everything that you might do “someday”, here are a few methods to ensure a fresh backlog:

  1. Like a grocery store, get rid of the stories that are past their prime.  I call this “pruning the backlog”.   Delete any stories older than 3 months.   The typical excuse is that we can’t do that because those stories are important.   Ask yourself – if they were that important wouldn’t you be doing them now or have already done them?  Remember, your goal is to maximize value, not volume – and that includes the number of stories in the backlog.
  2. If you are using Scrum, limit the number of stories in the backlog to either 3 sprints worth of stories (you are counting stories and not using story points, right?).  Similarly, limit the backlog size 3 to 5 weeks throughput if you are using Kanban or some other method of continuous flow.  And only fully refine stories just before you need them by understanding your cycle time.
  3. If you’re using SAFe, only refine and plan enough work for the next 2 Iterations for each team.  This may include work from the previous Increment.   Most Scrum teams will already have their Product Backlog refined to this point, a couple sprints worth of ready to do work.  Refining and planning anything beyond the first 2 or so Iterations is adding risk.  The further out you refine and plan the greater the risk that that work and money will become waste if situations change and you need to pivot, either from changing market conditions, feedback on current work, or any of many other potential factors.  Only planning the first 2 Iterations will likely mean you can reduce a multi-day event to one day at most.   Team’s will already have this amount of work refined in their backlog so no pre-planning or pre-work is even necessary.   Then the PI Planning event becomes simply an exercise in review team level backlogs and negotiating dependencies by actually scheduling the conversations rather than simply identifying them and agreeing to talk “ some day”.   Let feedback from the Iteration Reviews inform the work for the next Iterations.   Now go celebrate all the time and money you just saved and the amount of risk you reduced.
  4. Measure and track User Story Lead time and Cycle time.   Frequently look at the difference between the Lead time and Cycle time.   That value will represent the time that the user stories spend in a backlog somewhere.   Perhaps they are being refined but those stories represent ideas that are getting stale, they are inventory at rest – your customer derives no benefit from that great idea during this time.   Work on reducing the difference between Lead and Cycle time to ensure your ideas stay fresh from concept to cash, or the time that customers can actually use them.

Wrapping Up

So the next time you’re reviewing your backlog, check those creation dates!   Are you providing the freshest ideas to your customers or moldy, stale ideas that are well past their use by dates?   Experiment with the ideas in this episode to keep your customers happy by only spending your valuable time and effort on the freshest of new functionality.

If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.

Until next time!

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
The Scrum Master as a Title Anti-Pattern

The Scrum Master as a Title Anti-Pattern

A practice very common in organizations is to hire Scrum Masters as an official

Next
Enhance Scrum with Kanban Practices

Enhance Scrum with Kanban Practices

Want to up your Scrum game?

You May Also Like
Total
0
Share