This is a very old and tired topic that seems to persist. I wish people could be past the idea of treating backlogs as ‘must do’ lists. A backlog to me is a place where ideas, risks, and assumptions go. They are things that we want to learn from. It is comprised of problems to solve for our customers, challenges we have as a team, and experiments to carry out.
More and more I am seeing backlogs that are full of specification requirements to build some feature, functionality or capability. Backlogs with ‘user stories’ that have every possible design detail and mock-up already loaded in it. Front-end, Back-end, QA, UAT and Deployment stories. This level of dysfunction causes such turbulence amongst people trying to work collaboratively.
Some view this way of working as ‘the one right way’ simply because of the false feeling of control that is gained. And if that is your deal and it works for you, live and be well. But know there is a better way.
Taking the example of a backlog to deliver a feature, functionality or capability. If you have a backlog full of ‘user stories’ that describe every detail and what it will look like and how it will behave and what the user will do with it, you are in for a surprise when you deliver this to the actual user. You will inevitably hear that “Now that I’ve seen it…” statement and let the dreaded ‘rework’ begin. Why continue to work this way. Even if you work with a story map, which I love to use, if you take every story from the map and spend the time to mock-up everything and get the ok from the user on the mock-up, then deliver all of the stories, there is still a great deal of risk in what you are delivering. And the frustration will mount here as the user says “Now that I’ve seen it…” and you say, ‘Well you saw it in mock-up or when we did the review, or when you viewed the prototype…” And we all know that conversation goes nowhere.
And to think this all stems from the, in my opinion, misuse of a simple concept of a backlog. Working still with the assumption that you are delivering some feature, functionality or capability. And that you have engaged with your actual user and created a story map. And during those conversations creating that story map with your users you’ve narrowed down what was needed to solve whatever problem this feature, functionality or capability is meant to solve. Fantastic work on your part by the way. Resist the urge to go story by story detailing everything in each one before you start creating. Just take the first story from that narrowed vision and start working on it. While you are creating it, ask your user to look at it with you. Or better yet, ask if they can be with you while you are creating it so they can fill in the gaps where needed, and they can say “Now that I’ve seen it…” in real time.
Yes, once again, this all comes back to STEERING! We want to be able to work in a way that allows for continuous steering. Over the years we have always said that software is only truly valuable and the users of that software can only provide us with real solid feedback once they can use it. I would argue that there are better ways of working that can allow for the user to steer and provide that precious feedback during the creation of the software as well.
And this can and does also happen when not working with a new product or story map. It tends to be less complex at times even. Look at your backlog with your customer or user and ask, “Which one of these problems should we try to solve first?” If the conversation starts to get into “Well we already designed this one out and know what we want…” that is fine. I would say “That’s great you have a vision! Can you join us while we try to create this for you in case we have questions or you see something that you didn’t think of before?” And if they can’t then I would ask which problem to solve is important enough that they could give you and the team time to work together on solving it. And eventually you are on your way. Yes, it really can be just that simple. And Yes, I have experienced this multiple times. And No, you don’t actually have any real constraints to trying this. It may just change the entire way things are done in your team or organization.
I am not and never will say “this is the one true best way of working”. But it by far has been the most beneficial in my experience to date.
I wanted to keep this short. How you treat a backlog is directly related to how well people will be able to work collaboratively to solve problems, learn and experiment. How you treat your backlog also can provide power to your customers and users to steer the direction of the product you provide that they will pay to use. It also gives your customers and users a vested interest in the outcome. And that STEERING results in great impact.
Chris Pipito 
2 thoughts on “Backlog Dysfunction”