In Friday’s email I sent a list of things that can slow down your software delivery.
While there are many technical reasons why this can be the case (tightly coupled architecture, lack of modularity or microservices, technical debt, breakage in production) there are also many process-driven reasons.
Right up there, for process-related delivery slowness, is your product backlog.
Most software shops work Agile. Ask yourself, when was the last time you got a user story through to production?
In more detail, what happens to your ticket when you get it onto the backlog? Is there a single backlog for your product? Do you have a personal responsible for that backlog (a Product Owner)? Is that person the only one who decides on priority?
Some more signs that your backlog is the problem:
- Your stories are placeholders and detail is filled in on the fly by developers.
- User stories live from sprint to sprint. Sometimes longer.
- You have duplicate stories with big functional overlaps.
- You user stories describe technical improvements.
- Your ‘spikes’ outnumber your stories.
The point of being agile is to be able to react quickly to changing requirements. If your backlog is a mess of spaghetti stories, then your sprints are full of meatballs.
In other words, it’s time to clean up.