Idea debt

Idea debt

I read a really interesting article the other day called “Kill Your Old Ideas So You Can Be More Creative” by Nick Douglas. Nick was discussing how proactive it can be to have a clear out of old creative ideas and how this has helped his creative processes, specifically with writing a screen play. Set your ideas free on the world so you can focus on the important ones.

This got me thinking about the concept of idea debt in relation to a backlog of work for a software product. We predominantly think of the product backlog as a collection of ideas or stories that have a positive value. Indeed it’s the Product Owners job to ensure that items with little or negative value don’t get onto the backlog. The use of that ever so hard word “No” comes into play.

Eroded value

The value of items that made it onto the backlog obviously varies over time as market conditions, new opportunities or company direction change. So the value of ideas that may once have been high can erode until those ideas can become worthless (certainly worth less). Although they will spend their life lurking at the bottom of the product backlog they will create an administration overhead when the backlog is managed. They cloud transparency as it becomes unclear where the end of the product development is likely to be. They can have a negative impact by deterring the desire to add more high value ideas as the backlog can seem unwieldy.

So we should be as ruthless with our trimming of of low/no value items from the backlog as we are with adding them. If they’re no longer valuable then park them or bin them. Don’t let them linger

Detail debt

Another aspect of idea debt is when a high level idea that the stakeholders have deemed highly valuable always sits at the top of the backlog. However these items are repeatedly blocked due to stakeholders or specialist customer resources are never made available to collaborate with the team so that the high level idea can be thrashed out. This idea debt demotivates the team as they can see a high value deliverable but they’re not able to deliver them.

There are a couple of approaches you could take here. You could deem that if nobody is available to help provide the detail then actually the value isn’t there. Push it down the backlog until detail can be worked on. Alternately if the team are brave they can run a spike task to generate what they think is meant by the high level idea and then demonstrate this to trigger the conversation. The choice obviously depends on the confidence and size of the task.

Conclusion

My conclusion to all this is that the Product Owner role is really hard. Saying “No” to a customer request is not an easy thing to do. Telling the customer that you are going to bin some of their low/no value stories is even harder. Customers often feel that if something has made it onto the backlog then they will get it at some point. The longer it’s been on there the more secure that feeling is that it will arrive at some time. As a Scrum Team we need to support the Product Owner. We need to make the conversation about doing more high value work rather than just cutting low value work. We need to give out Product Owners options. We need to remind the organisation that the product owner must be empowered to make decisions, without this they will not feel they can say “No” and they will not cut out low value ideas. A lot of Scrum is focused on technical debt, how to deal with blocked development and general development. Without a clean, high value, backlog of items that can be worked on we can’t leverage the great value the framework offers.

 

 

Leave a Reply

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