The backlog is a great idea: all the things we think the team will build, or perhaps: things they might build, and it might contain other work, like evaluation or reviews. Yes, the backlog is a great idea, all the stuff the team might do, well perhaps not all, it is seldom complete, after all, as they say “stuff happens”.
The truth is: backlogs have a tendency to grow. All too often I find teams who are struggling under the weight of their backlog. They can’t spare time to do experiments or learn something because there is stuff to do. The backlog becomes a tyrannical ruler and all of it MUST BE DONE.
Look at that hypothetical burn-down chart above. By sprint 15 the team is well on its way to completing all the original work. But the amount of work they need to do is higher than when they started. It is not as if the team have been doing nothing. Look at the next chart, it shows how, most weeks, more work is added than is done.
To my mind finding more work isn’t a problem, indeed teams should be finding more work. Problems stem from the fact that backlogs – and tracking mechanisms like burn-down charts – try to full-fill competing needs.
- The backlog is used as a store of ideas for work to do. This makes sense, you can’t do everything today so postpone some to the future. A backlog allows you t move some things from peak time to off-peak, although software development teams rarely seem to see off-peak time.
Plus, having a backlog makes it easier to say:
“Thanks for your suggestion Fred, I’ve added it to the backlog, I’ll let you know when we get to it.”
Rather than:
“Thanks for your e-mail Fred, we deleted it once we stopped laughing.”
It makes sense to give a new idea a quick once-over. But doing a proper analysis is time consuming:Discussing what is being asked for takes time, as does setting acceptance criteria are. And then there is business value to assess and other work priorities to consider. Therefore, put it in the backlog and do all that later (if it ever gets scheduled.)
Without a backlog we would be forced to make a binary decision: do it and do it now or reject it.
In fact the backlog can become a natural filter: as stories age in the backlog some items will jexpire. Unfortunately many Product Owners don’t feel they have the authority to delete old requests so the backlog grows and grows.
I call such a “constipated backlog”: work goes in but very little comes out. When the only way for items to leave the backlog is by doing them the rate of return falls.
- The backlog fills another role because so many teams are still expected to meet project success criteria which ask for “everything to be done.” The backlog becomes a tyrant when people believe that one day it will all be done. Worse still, some people plan using this assumption.
People want to know when “it” will be done, how long it will take and how much it will cost. It takes time to answer those questions and if the backlog is growing any answer is going to be wrong.
In fact, it is probably wrong to think everything will ever be done. Unless one freezes the backlog and refuses to add new work then it is likely that low value items will be postponed while new, more valuable items, will take priority.
As an industry we need to drop the idea that a backlog will ever be done: the backlog as repository of ideas is at odds with the backlog as a measure of completeness.
Think about it this way: some of the items in the backlog are very valuable. Some items are worth very little. Some will cost more effort than the benefit they bring. If we do everything then the low value and the high value will all get done. Conversely, if we encourage new ideas and weed-out as many low value items as possible our rate of return will be higher.
But very few teams follow this model. Many more teams are slaves to the backlog, and their quest for an empty backlog is doomed.
Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Tyranny of the backlog Opinions expressed by Java Code Geeks contributors are their own |
