I’m sure Alanis Morrisette would agree with me here, because isn’t it ironic that businesses so often favour pushing out new feature development with complete disregard for the importance and need to keep on top of Tech items, such as tech debt, non-critical defects, upgrades and even license purchases or renewals.
In evangelistic Scrum, we know we have ‘One Backlog’, which contains everything on the Product Owner’s wish list of work items that make up his or her product, including tech items. We also know that anyone can add to this backlog, such as developers being able to add tech items but only the Product Owner can prioritise this list.
When it comes to managing tech items, I have a slightly different approach for this, and yes, I have broken the One Backlog rule… and yes, it felt good…
I have found that it is a good idea to have a separate Tech Backlog. The Tech Backlog is exactly what it says on the tin. It is a prioritised list of Tech items that need refining in order to be added to a sprint. Who owns this backlog, you say? The Scrum Development Team do. They all act as one Product Owner to take ownership of the Backlog and make sure the Backlog contains all the items they know of in order to keep the system or product in as good a condition as they can be. Like any backlog, there may be Epic size items and granular items. Higher priority items should be refined. In terms of ‘user stories’, I do not ask the team to create user stories for Tech items. Instead, I ask them to ensure that the item contains enough detail in order for anyone on the team to be able to understand and pick up the item in a sprint. The term ‘enough detail’ is up to the team. They should know what that is. If they don’t add enough detail, then the they are letting themselves down, and they are not ‘setting each other up for success’. Team members should be encouraged to reprimand each other with severe punishments if they do not set each other up for success. Only joking…. No, the team should be encouraged to communicate effectively so that everyone is aware of what ‘enough detail’ means, if anyone is unclear. Not requiring the creation of a user story is another reason why I think the Tech Backlog should be separate to a new feature backlog. The people that need to understand the items are technical, therefore I see no need for ubiquitous language via a story. The final benefit is that having a separate backlog that the team manage is easier than them sifting through a larger backlog full of business items they don’t understand or care about yet. Equally, it would be very hard for Product Owner to be able to prioritise technical items. An additional benefit to having a separate Tech Backlog is that there is visibility of a Tech Debt problem to a Product driven Business. Having tech debt as long as your arm that is plain for all to see is difficult for even the most archaic Project Manager to argue with.
A way I like to help a team to get organised and take ownership of the Tech Backlog, is by setting up a Tech Backlog Story Time meeting. For more information on Story Time, check out my blog called Story Time, Yey!
Like the new feature Story Time that involves the Product Owner, the Team hold their own Story Time in order to discuss their candidates for the next sprint from a tech perspective. Hopefully, the Product Owner should respect the value in tech items and allow either a percentage of the team’s velocity for it or, better still, be open to having as many tech items as the team feel necessary in order to maintain a great system, and support a great product. A sprint backlog should be the result of a negotiation between Tech needs and Business needs. If your organisation does not respect the need for Tech items, then it’s up to the ScrumMaster to work on some organisational change and start explaining the benefits to key stakeholders.
I usually set up a Tech Backlog Story Time for the team before the New Feature Story Time meeting. This can be the day before or even an hour before, as long as it’s before. I do this because if their meeting is held before the candidates for new features are known, the team are less likely to be influenced by what the PO wants in the next sprint, and concentrate on what is needed purely from a tech perspective.
So there it is, the Tech Backlog. A way of keeping track of tech items and chipping away at them in a controlled manner via being organised, discussing priority and negotiating with the Product Owner to get them into a sprint.