Backlogs often become a dumping ground for ideas. Some of those ideas are good, others might need some exploration before we understand if they’re worth it or not, but many of them are often not worth pursuing. After some time, it can be cumbersome to start to trawl through an ever increasing backlog to find the right value item that you should start to explore.
If you’re using a backlog and not thinking of them as options, please refer to an earlier blog post that talks about using options instead of a backlog (from here on, I’ll refer to them as options):
Options have a value at a point in time. Generally they have a cost of delay. There’s also a cost of retaining options for too long – think about a options list that has a thousand items in it, how long is it going to take for you to find the top 10? You need to regularly trim your options list to make sure it’s lean and gives you insight into what are real options you need to spend your time on.
Put it another way, if you’ve had an option in your list for a year and haven’t taken it up, how likely is it that you’re going to take it up in the next year? For that matter, if you’ve had an option in your list for six months and not proceeded, how likely is it that you’ll take it up in the next six months? Or three months? If you’re thinking to one / all of these that it’s not very likely, then you’ve really just hit on your option expiry date. After a certain amount of time those ideas have expired.
Think about your answers to those questions. The one that’s the shortest to which you answered “unlikely” is your option expiry timeframe. Record the date that an option enters your pool of options. After the amount of time you discovered above (say it’s six months), that becomes your option expiry date.
Periodically remove those options that have exceeded that timeframe. Just throw them away. Even better, if you have an electronic system, set a rule to do it for you. Don’t worry, if it’s really important it will come back and you can create another ticket.
Doing this will save you time and help keep you focused on things that are important right now.
I’ve heard this being said a number of times with teams and it often reminds me of the story the Jeff Patton told in his book “User Story Mapping” when he was talking about requirements. In that story, when he was trying to get a better understanding of the underlying need being requested he was told “They’re requirements” – to which he likened to being told to “shut up”.
When I hear the term “It’s on the backlog” I think that’s another way some agilists are telling others to “shut up”, or at the very least “go away”. Often it’s not followed up with more honesty like “we don’t intend to build that”, or at the very least “it’s not likely to be built in the near future”. Sometimes this is a way of saying “No” or “Not yet” where it can be difficult to say this flat out, but is it the most respectful way to treat people?
How about instead try something along the lines of “we can add a ticket to our pool of options, but it’s not likely to be implemented anytime soon, if at all”. You might find that this change in terminology gives your stakeholders greater respect and builds on the trust and transparency that you need to build a more stable foundation for a longer lasting relationship. Also, you’re starting lean towards the use of language that supports probability / likelihood rather than absolute certainty. This incremental step can be built upon later with greater use forecasting.
Often we become constrained in our thinking by the language we use – a good example is the use of the term “backlog” instead of “options”. Quite often if you say to someone “It’s on the backlog”, the perception is quite often that although I might not get it now, it will become available sometime. However, in reality this is often not the case – or should not be the case. If we change the wording we use, we’ll create a more accurate representation of what is actually, or should actually, be happening.
Definitions from the Cambridge dictionary:
Backlog: “a large number of things that you should have done before and must do now”
Option: “one thing that can be chosen from a set of possibilities, or the freedom to make a choice”
Commonly, the term option is used in the context of the stock market, where you can have an option to buy shares (or not). You have the choice – it’s not an absolute.
As you can see from the basic definitions above, they are quite different and the impression that they can give stakeholders, also, would be quite different.
The above definition of backlog implies a fixed scope – “must do now”. However, to truely be agile we shouldn’t be committing these kind of things up front as we’ll learn along the way and what should be done will change as we learn.
Try to stop using the term backlog, and instead replace it with the word(s) “Option” or “Pool of Options” and see what effect it has to the conversations with your customers and stakeholders. You’ll be able to defer commitments to a more reasonable point in time and have that process better understood. Additionally, you’ll likely find that you’ll have earlier conversations as to whether we should discard some options, rather than keep maintaining the illusion that something may get done.