Chris Jones, our Client Services Director, once wrote a line in a proposal which I’ve been quoting ever since, exclaiming the stupidity of sticking to a technical specification that is six months old.
That’s of course part of the problem agile solves – keep your backlog flexible; decide on priorities as you go; allow yourself to learn and adapt.
A backlog is not a specification
At White October we make agile work pretty well. The closest we get to a specification is the estimated backlog that a user story mapping session spits out. I make a big thing about that backlog – my golden rule: never start a project without one.
But a backlog is not a specification.
It is not a description of a finished product.
It is the raw material out of which we’ll create our product, and our best guess at its size.
<blink> **** Contrived teapot analogy warning! **** </blink>
A backlog is the equivalent of an un-moulded lump of clay. We know that we want to make a teapot that serves tea for 4, so we get approximately the right amount of clay on our potter’s wheel. We get it spinning and start moulding. As we go we add bits, we chop bits out, we change its shape, sometimes dramatically, near completion we add finer touches like a handle and spout, and we etch our initials into the base.
The backlog is clay in your hands
The backlog is there to be pushed around, moulded, challenged, chopped up, thrown away, twisted and turned until our product materialises. Our collective experience in the project, what we learn and hear from users, the discoveries we make as we build, are how we decide to adapt the product. As a potter uses their fingers to sense and control the changing shape of the pot on their wheel, so we use our collective insight to adapt our backlog.
Challenge and adapt
Backlog grooming is not about prioritising our list; that is no better than building to an ancient specification.
It is about challenging each and every story in the backlog and making sure that today it is still a sensible thing to build. Can we make it simpler? Is it definitely needed right now? Are we certain users will use it? Does it represent value to our customer? Is there an alternative way of thinking about it?
Sticking to a backlog is lazy thinking
Scrutiny of the backlog is the collective responsibility of the team. All members of a highly functioning team at White October will sense check every story that gets planned for a sprint and push back on items that don’t make sense anymore.
We’ll campaign for simplicity, and demand evidence of business or user need.
Disrespect the backlog: half of everything in it is wrong.
The backlog, written when we all had maybe one or two days contact with the project, is guaranteed to be flawed. One month in you will have 10 times as much insight as you did when you helped write the backlog. 4 months in and if your ideas haven’t changed dramatically then you’ve been sleepwalking through the project.
Half of everything in that backlog is wrong – your job is to put it right.