How agile is your backlog?
Software developers like lists. They like to log-on and focus on working their way through a list of deliverables, checking them off one-by-one as completed. Developers like it even more if they are given clear requirements for each of those deliverables, because having to dig up or define your own requirements requires context switching away from development. Context or task switching away from development is a form of process waste—see my previous post, “Eliminating Web Development Waste“—and software developers do not like wasted time.
When we adopt an agile process for software development, the product backlog becomes the list of things to complete. It is at this point I often see developers exhibiting frustration because the backlog is no longer as clear as the to-do list they had made for themselves. When faced with this frustration, my advice is to remember that the backlog is a list of work items for greater audiences than the development team.
The backlog provides a product source-of-truth for everybody; from sales through to support. Each item in the backlog needs care and attention to ensure it is easy to read, contains all relevant reference materials, and provides enough explanation that anyone in the business can understand the user need and the proposed solution. That said, it’s also important that everyone accepts that each item in the backlog is a work in progress, and that gaps should be acknowledged (but filled in as soon as possible). Being agile means we should recognise it is a pipe dream to expect perfect requirements for every user story or task we undertake. Change is inevitable, and the agile manifesto acknowledged that when it stated:
Customer collaboration over contract negotiation
Responding to change over following a plan
Over the past few years, I’ve worked with a few businesses that have started down the agile path for the wrong reasons. They believe it will make them faster, because they’re delivering incrementally. Inevitably, these businesses then get into all sorts of issues because they fail to adapt their processes to allow clear conversation between the actual users and the developers. Agile is not about speed of delivery but speed of correction, and every layer of business function between the folks using the software and the folks designing and building it is a layer of misdirection in that correction.
The whole point of iterative development and incremental improvement is that we have a shorter feedback loop. We avoid veering off course from the user’s requirements and deliver small improvements, instead of one massive release that somehow lost its way and missed the brief. What’s more, good feedback requires direct exposure to users, who can tell us whether we’ve hit the brief or whether we’ve missed something.
Which brings me back to the backlog being a list of stuff to do. Being agile also means recognising that one user-story or epic does not have to be the final word for a given feature. Stuff gets missed. Stuff ends up broken. It is entirely acceptable to create further tasks and stories to patch stuff up, even if we’ve already delivered an epic for that feature. The best agile backlogs are made up of a lot of tiny deliverables with very simple acceptance criteria that help us avoid over-engineering but that iteratively build up to a whole that is greater than its parts. Write your stories and tasks to deliver value against a clear user need, but with the minimum viable acceptance criteria. Anything else can come later.
So next time you’re irked about the backlog, remember:
- It’s not just for you; it’s for everyone, including the users.
- It’ll work better if you keep user stories and tasks simple and direct.
- Improvement between iterations requires feedback and conversation with everyone, including the users.