And the noun means
“2. an accumulation of tasks unperformed []…“ – Merriam-Webster online dictionary
Translating the word to German makes it even worse: According to dict.cc amongst the German translations there are:
- Rückstand (lag, deficit, handicap)
- Nachhohbedarf (a need to catch up)
So clearly there are some negative connotation with regard to the term backlog. Still it has become a term with positive connotations in the software development community within less than two decades.
Yet –regardless of the positive connotations–, time and time again I see backlogs used in a way that seems counterproductive to me, Accumulating more and more “undone work” in the “backlog” - whether it is called backlog or feature-list or ticket-store or any other name.
In these cases, the items in that list really become a “Rückstand” as we would say in Germany - a lag with a need to catch up!
Of course there are several countermeasures to this – Backlog Grooming probably being the best known. But lean approaches also point to another idea on how to handle this: be very well aware of what your backlog really is and what you commit to!
Backlog vs. Ready-Column
Little’s law tells us that the average time an item spends in the system is determined by the work in progress divided by the time it takes to work on one item.
If we trust in this formula, basic mathematics tell us that if we put infinity in the numerator the result will also be infinite.
Thus, if we don’t put a limit on our backlog, we do not have a predictable time to completion.
Let‘s draw a picture of that:
Very often task-boards, scrum-boards, informal kanban-boards etc. are organized like this:
An unlimited input column (in Scrum for example it is the product-owner‘s job to keep the backlog prioritized the right way, resulting in an ample amount of preselected work for the next iteration), followed by some columns for the different stations in the process and finally an unlimited column for the finished work. While one might argue about the last one – which would make a good topic for a post on it‘s own – in general there is nothing wrong with this setup.
The problem arises when people forget that they can‘t make predictions about the whole board. Since the first column is endless (i.e. not limited) the average time any item spends in the system implicitly also goes towards infinity.
Now for the simple solution:
Only promise what you can control!
Without changing even one stroke on your board, just by communicating clearly that the predictability begins where the control begins, a significant change in expectation management might occur.
(Of course this was originally part of most agile approaches - it just happens that nowadays it seems to be forgotten from time to time…)
Shifting to an input queue
While we‘re at it: Why not change the wording to reflect the difference? While a _‘backlog’_ is a – potentially endless – list of things ‘not yet done‘ what we really want to talk about is a list of thing ‘to be done in a foreseeable, defined future‘. For me, one term that captures this concept nicely is the _‘input queue’_ – a term frequently in use in the lean community. And while I‘ve seen many (product-) backlogs without a limit, I have not yet come across an input-queue without a limit.
’till next time
Michael Mahlberg
No comments:
Post a Comment