Dave West wrote an article for InfoQ suggesting that backlogs are very important, in fact essential, if software development is seen as theory building. This article had several readers pinging in with their opinions which were all accross the board. Later, a discussion picked up again on the leanagile Yahoo! Group. The interest and/or conflict that this article indicates that this is a point that can benefit from further clarity.
To that end, InfoQ contacted several thought-leaders in the industry: Mary Poppendieck, Ron Jeffries, Jeff Patton, David West, Steve Freeman, and Jason Yip to explore this issue further. We asked them to address the following points:
- What is the purpose of a backlog in your opinion?
- How would you define a backlog?
- When/where should a backlog be considered waste?
- When/where should a backlog be considered essential?
- Is there a question or questions that I should have asked and I haven't? If so, please ask and answer.
Here are their answers: (note: Mary Poppendieck's answers were in an essay entitled 'Redefining the Backlog' and at the bottom of this article.)
What is the purpose of the backlog in your opinion?
Steve Freeman:
To give the team a sense of where they are and where they might be going. It should be taken with as much seriousness as it deserves.
Ron Jeffries:
There are probably many purposes. Two that I'd like to discuss,
because they differ in value, are:
1. To keep track of things one might like to do someday.
2. To communicate to others the status of their requests.Jeff Patton:
The backlog, for me, serves 2 purposes: First it helps me understand the "shape" of the product I'm building - what it is, what it could be, who it serves. I understand that shape at a high level - a "big story" level. For me this resonates with what Dave described citing Alistair on Nauer as "theory building". It is, and should be - we need to do that. I use the idea of the backlog as a "story map" to communicate the theory: http://www.agileproductdesign.com/blog/the_new_backlog.html
But - at some point in time we need to decide what to build - and ideally just in time - and then stories become a backlog of scheduled work. But only for the work I've specifically chosen.
Stories and a backlog are two things - at least. The name backlog isn't "intention revealing" when it comes to the backlog's role of trying to communicate some of the theory. And because of the bad name, and because it takes some skill and understanding to use it to communicate theory, I don't think most people do.David West:
The purpose of a backlog derives from the purpose of a user story. A user story was intended as a mechanism to empower users (customers). It was to be written in the vernacular, in a conversational style, and was to capture something that the user wanted from the system - an aformal (not informal) expression of an expected behavior/responsibility. A story is also a way to partition and focus work, hence the need for a story to be estimable, complete-able within a single iteration, refactored if too ambitious, etc.
A story card is a reminder of a conversation that was started -- and is to be continued -- between users and developers until the software fulfills the expectations of the elaborated story. The conversational process will emit other ephemeral and persistent reminders of the story: models on whiteboards, tests, working code.
None of these artifacts, including the story card, have any purpose other than to be tangible reminders of what the user wants and how the user understands what she wants and how the developers have interpreted what she wants. The are tangible evocative (recalling to mind) evidence of the intangible understanding and communication between user and developer.
The collection of user story cards is tangible evidence of a meta-conversation, this time, almost exclusively, among users. The meta-story concerns priorities (how important is this story in business terms?), communities (am I the only one that wants this?), plot and character development (your X object and my Y object are really the same, seen from different perspectives), alternatives, variations, etc. This meta-conversation is modified by feedback from the completion of individual stories and is ongoing for the duration of the software project.
The preceding leads to the conclusion that there is a collection of stories that serve as tangible reminders of an ongoing conversation about what the users want and how they think it will help them and their organization. If you want to label that collection of story cards a "backlog," you do so at your peril - you are making a semantic mistake and subverting the collection into being something that it was not intended to be. But if you insist on the label, then: the purpose of the backlog is to serve as a tangible evocative reminder of an ongoing, multi-threaded, mult-participant conversation and meta-conversation about a software system.
Jason Yip:
If we assume Sprint Backlog, it provides an explicit agreement of what work is targeted for the current Sprint. If we assume Product Backlog, it provides an indication of potential features for the product. In this case, it also helps communicate a vision of the overall product but the typical flat backlog is quite ineffective in doing this. Using tools such as Story Maps, Parking Lot diagrams, process maps, etc. to place the backlog items in context is better.
2) How would you define a backlog?
Steve Freeman:
1) A thinking tool to help the team understand its relationship with its customers
2) A rough cut list of features that represent our current best guess of what we will need to provide.Ron Jeffries:
A backlog is a list of features planned items, held in the order of
their current priority to the "backlog owner".Jeff Patton:
Again, hate the name: "backlog"
Again it's two things.
The _organized_ list of stories are high level details of what we understand of the theory of the product.
The _prioritized_ list of stories - with uncommitted stories excluded is a backlog of scheduled work.
Which means you have to understand the difference between organizing your backlog, and prioritizing your backlog.David West:
A "product backlog" is a collection of stories that reflect our best, current but subject to change, understanding of what the user wants from a software system. An "iteration backlog" is a set of conversations that we (the development team) intend to complete in the time interval defined by the iteration. An iteration backlog does assume the role of a to-do list, a kind of inventory of work. Each story conversation generates reminders of additional things we need to do to advance the conversation and to assure we have the feedback needed to keep the conversation on track. An iteration backlog assumes additional duties (supporting iteration management and tracking) without ceding its original responsibilities (tangible marker of an ongoing dynamic conversation).
Backlogs are NOT sets of requirements.
Backlogs are NOT inventories of uncompleted work.
Jason Yip:
A queue of potential items to work on. Backlogs are more effective if they are prioritised, if they are placed within the context of the task and process flow and overall product vision, and if item detail is deferred until they get closer to the front of the backlog.
3) When/where should a backlog be considered waste?
Steve Freeman:
Tautologically, when it takes more effort to maintain than it provides value.
For example, in a maintenance/support environment where it may be more effective to turn decisions around quickly than to store a lot of possible requirements. Or in an environment where requirements change dramatically.Ron Jeffries:
I think that backlogs are not really very wasteful. They are just a list of items. As they are in priority order, there isn't frequent need to look at many items other than the ones toward the front.
That said, it certainly takes more time to troll through a long backlog compared to a short one, so it can make sense to just drop all the items whose priority isn't very high. I would expect a sort of power curve in a backlog, which suggests to me that 80 percent of the "naturally-occurring" items are probably not very important and could be dropped with little harm.
Backlogs do consist of a kind of /muda/, activity consuming resources without providing value, since they don't provide much value. This is especially true when a published backlog is misleading, giving stakeholders the illusion that their ideas are in process when in fact they are waiting and will likely wait forever.
Why do I say that they will likely wait forever? Because an item on the backlog which has not been chosen to be done is of lower value than the things which are chosen. That being said, it is very likely that new ideas will come along which are also of more value than the waiting item. These will be inserted in front of the waiting item ... and this will likely continue indefinitely.
In essence, there is a line fairly close to the front of a backlog, such that if you are behind that line, your idea will never be implemented. When this is the case, a better idea is just to tell people they're out of luck, and drop the item entirely. This leaves the idea's original owner in better shape to make a decision, such as to provide that item in some other way.
Jeff Patton:When you've scheduled and detailed work far into the future, and far ahead of understanding if the work is really needed.
David West:
There are two circumstance in which backlogs (product or iteration) become waste.
One, anytime they become "archeological." By that I mean the stories devolve into nothing more than markers of discussions of conversations we once had. The collection of stories reflect nothing more than our understanding of the system on the day we started the project. Each story becomes a 'stone tablet' - an unmodifiable, purely syntactic, statement without context and therefore without semantic meaning. The collection of stories become nothing more than a historical document the confirms the degree of our ignorance way back then.
Two, when story collections (backlogs) are subverted to serve the purposes of 'management' or 'production tracking.' Agility really is (trite phrase) a new paradigm. Agile is a different culture. Force of habit, laziness, and the pressure of the formalist culture in which we live, constantly strive to shove agile and agile practices back into old and established paradigms and cultures of structured/engineering/rational/scientific development and Taylorist management.
Jason Yip:
The backlog is always waste.
4) When/where should a backlog be considered essential?
Steve Freeman:
Where you need /some/ sense of how much is left to do, for example where you have to coordinate with people with longer lead-times such as marketing or people installing kit.
I think it's worth distinguishing between different levels of backlog, as Scrum does with its Product and Sprint backlogs. It may be unreasonable to expect product people to only look at the next 5 items because they have a larger picture to deal with -- but that might be all the dev teams needs to work with. If we really want to make motor manufacturing comparisons, it's like the difference between the Toyota Product Development system and the Production System. The former has lots of waste because they need to have designs ready on time.Ron Jeffries:
Essential? Probably very little in the world is essential.
A backlog has value with it serves to communicate what is really going to be done. As the truth of the backlog declines, so does its value. This suggests that shorter is better.
A backlog has value as one means for considering the things we might do next, and choosing some and refining their definitions for implementation.
A backlog has value to some people as a list of things not to forget. Many people may have more things on that list than strictly need to be there, but it seems to provide comfort.
Jeff Patton:
The understanding is essential. If you use the backlog as a tool for understanding, its always essential. If you don't know how to do that, it's not.
David West:If you are really committed to doing agile development, when you want your software to reflect a deep understanding of the domain, and when you want your software to support and enhance real people doing real work in the real world.
Jason Yip:We need to know what to work on next including whether it's appropriate given a larger product objective. It is useful to have a broad view of what an overall product might look like. If we don't choose a Scrum-style backlog to satisfy these needs, we need to have something else.
5) Is there a question or questions that I should have asked and I haven't? If so, please ask and answer.
Ron Jeffries:What are good and bad ways to represent a backlog?
Keeping the backlog in some form of computer store is tempting but dangerous. The computer can keep a huge amount of information, and the result is almost inevitably too many items written down in too much detail. If ignored, these items are waste. If paid attention to, most of them waste time.
Keeping one's backlog on index cards has some great advantages:
You can't carry many index cards around, so the backlog size is self limiting.
An individual or a group can ready prioritize a stack of index cards by just laying them on a table and pushing them around. The process is easy, efficient, and highly participative.
You can't write much on an index card, so the unnecessary details are kept down.
It is easy to tear up a card and replace it with new ones. This make updating quite easy.
I could go on. Everyone "knows" why these things "should" be kept in the computer. In more cases than people think, the simpler approach is better on almost all dimensions.
Jeff Patton:
How do you use a backlog to understand the "theory" of the product? What else contributes to understanding the product's theory?
(No answer from Jeff.)
David West:
Why is everyone so wrong? (This presupposes, of course that I am right.) Or, an alternative phrasing, "why is there such disparity in our collective understanding of stories, backlogs, and agile?"
The short answer: we are techies, educated in departments of computer science and software engineering that respect nothing except the 'formal,' working in a culture that has little or no respect for the aformal and the "mystical." Collectively we have ignored Brooks' assertion of the critical nature of the "conceptual construct" and his observations about the inadequacies of mathematics, science, method, and models. Collectively, we ignored Naur's ideas about theory building, the ineffability of theory, the inadequacies of method and documentation. Collectively we dismissed the idea of objects in favor of abstract data types. We dismissed Alexander's Timeless Way of Building and QWAN in favor of documenting solutions to problems that arise from not understanding the art of design. Collectively, we are subverting agile culture, philosophy, and values by forcing them into old ways of thinking.
Mary Poppendieck answered the questions by restating the problem in this essay entitled "Redefining the Backlog:"
I would like to start by observing that the term “backlog,” as far as I can determined, was introduced to the software development world by Scrum. I try to avoid using Scrum terminology, especially words like “backlog” that have developed several different colloquial uses. I believe that it is time to reframe the conversation around more precise terminology, for example, classic lean concepts such as queues, knowledge creation, and set-based development. A “backlog” has come to mean all three of these things, typically mixed together.
Queues are most appropriately discussed in an environment where a software organization has small frequent requests which come from people who would like something done to improve their work in some way, and the faster you can give those customers what they want, the faster they can realize the value they seek. In this case, it is almost always best to limit the number of requests you accept to ones that you have the resources to complete within a short period of time. The reason for this comes from queuing theory, and specifically Little’s Law: the average time to get a request filled is directly proportional to the size of the queue.
Thus when you have a steady stream of relatively small requests coming at you from customers, your response time will be proportional to the length of your queue. If the queue is short, you can respond quickly and deal with the customer need near in time to when it arises. If you can respond reliably and repeatedly in a known short time, then customers can come to depend upon your response time. If your response time can be relied upon, then customers can learn as much as possible about their problems before they ask for a resolution, because they know that their requests won’t have to wait in a long queue while their problem changes. Limiting queues length requires you to honestly give customers a rapid response when they submit a request: Yes you will, or no you will not, be able to address their problem. If you say yes, customers also know when they can expect the problem to be solved. If you say no, customers have the honor of being dealt with honestly, and they can make other provisions for solving the problem. They also come quickly to understand the limits of what is practical to ask for.
With this approach, customers are dealt with honestly and come to trust that the team can be relied upon. The team shows respect for their customers with an honest approach and reliable promise date. Teams become tightly linked to and deeply engaged in delivering customer value – and in lean, focusing on customer value can only be good. Knowledge creation is another huge value in lean thinking. Therefore, knowing what is coming at you, keeping track of what you've already considered, and understanding the many options for the future are very good things to do. Every customer problem is a learning opportunity, and you want to partner with your customers so as to have a view of where they are thinking of going in the future. When customers and development teams are good partners, they will spend time together keeping track of the each other’s problems, extracting knowledge from the experiments they have run, and alerting each other to the market and technology trends in the future.
Another good time for knowledge creation comes when you are doing a very large project and want a general idea of what is necessary over time - a product road map. This is a very good idea. I'm all for it, as long as you don't spend too much time driving the road map bullets down to small stories that will only have to be changed later on. Actually, even that might be okay if there is sufficient learning that comes from the exercise. Learning is always good. There are many devices that may be used to track knowledge. One recommended lean tool is the A3 document (A3 is a paper size outside the US which is about 11x17 inches). The idea is to distill all the relevant knowledge about a particular topic onto one side of an A3 document. An index card is an A6 size document – and in software development, people have found this size to be very useful in capturing knowledge about a particular customer value. It doesn’t matter, really, if A3 or A6 is the appropriate size, the issue is that you want to make tacit knowledge explicit and capture it in a useful way so you don’t have to re-learn and can make more informed decisions. These are very important lean values.
Set-based develop is an option-based approach to development. It is used to generate knowledge in particularly tricky situations where decisions are very expensive to reverse. It means that you develop several options quite thoroughly and then decide from the knowledge created which approach is best. You create a couple or three theories of how something will work and run experiments to compare the results against the theory. If the results disprove the theory, you need to improve your theory; if the results support the theory, it is strengthened.
The idea of using experiments to improve knowledge is also very effective for process improvement – so for example, the best way to understand the ideal queue length is to create a theory of how its length will affect important data points, and then run experiments with different queue lengths to see how the data points are actually affected.
As the reader can see, we are far from complete agreement about the backlog, but there are some very important threads in common that we find:
- It is important to understand the large picture of where you are going.
- It is important to understand where we are right now.
- From (1) and (2) knowledge creation, maintainence and dispersal is key.
- If a list is too long or too stale it becomes wasteful and more effort than it is worth.
