A common mistake that I see many organizations make when they purchase a backlog management tool (like Rally, VersionOne, ScrumWorks, etc.) is that they begin to see the tool as the means by which they will document their applications as well. The temptation is serious — these tools allow you to put your entire backlog online where it can be sorted, searched, printed. What more could you ask for! All of the information is already typed in, right?

In pursuing this solution, however, what many organizations are setting themselves up for is a HUGE problem over the long run when it comes to understanding what their product actually does. Let me illustrate. Let’s take a very simple product with three major features. We’re going to build it in nine sprints and every three sprints we’re going to release a version of the software to our customers. If we laid all of the backlog items we did during the nine sprints on the table it might look like this:

The backlog items with the “A” on them were all creating or changing (or even removing) characteristics of feature “A.” Likewise, the items with “B” on them all created, changed, or removed characteristics of feature “B.” Backlog items with the “C” on them all affected feature “C.”

So, keeping in mind that each backlog item added, changed, or even removed characteristics of a feature, describing how feature “C” worked is as easy as looking at the three backlog items that modified feature “C.” Not too difficult. Now, when version 2 begins, we actually have four backlog items that change feature C — two of them changes how C works, one extends C’s capabilities, and the last story removes some capability that our customers didn’t actually need. To describe how feature C works in version 2, we must somehow combine all of the creating, changing, and removing of capability of the seven backlog items completed so far. It’s a little harder this time.

Imagine describing feature C after we’ve completed ten backlog items (by the end of version 3). What about 50 backlog items after fifteen sprints? 100 backlog items after about 2 years? Just to make it a little more difficult, keep in mind that backlog items frequently change during the Sprint when the Scrum team (along with the Product Owner) decides to build the backlog item a little differently than thought during Sprint Planning.

As you can imagine, as your product gets more and more complex and more and more Sprints are finished, the concept of using your backlog to document your application, no matter how much information you put into your backlog management system, gets to be pretty unmanageable pretty quickly. The reason this happens is simple — backlog items are not intended to document how your product works, they are intended to reflect how your customers use your product. This is particularly true if, like me, you tend to use user stories as most of your backlog items. Backlog items are not intended to survive the Sprint in which they are properly completed. Once an item is deemed by the Product Owner to be DONE, the backlog item has lived its useful life and it is removed from the Product Backlog.

The solution to this problem can be simple depending on whether or not you are building a new product or bringing legacy products into the agile development world with you. In the case where the product is new, the documentation problem is easily solved by writing the specification at the same time you build the backlog item. If we look at the previous example, our specifications for features A, B, and C would be built incrementally during each Sprint.

Now, as each backlog item is completed the affected specification is updated accordingly (with some sections, shown slightly “dimmer,” being removed after the initial Sprint).

Of course, not everything is as easy as it sounds. Unfortunately, backlog items only sometimes confine themselves to a specific feature of a product (as in the examples I’ve provides). In reality, many backlog items will touch more than one feature of an application at the same time. That means that, while working on one backlog item, you may have to make changes to two, three, or even four different specifications.

Consider, for example, a backlog item that changes the product’s sign-in feature to support and require what’s called a “strong password” (this is a password that must be over a certain number of characters long and must contain a minimum of three different types of elements, including lowercase letters, uppercase letters, numbers, and special characters). A backlog item such as this might require changes to the UI specification that discusses the sign-in dialog, changes to the architecture or the authentication specification to support the requirements of a specific type of password, and changes to the database specification to support a password that may be longer than the password the application previously supported. So, when working on a backlog item, be prepared to modify several specifications.

When you are bringing legacy software forward into the agile development environment, your product specifications might be in a number of different formats. We’ll take a quick look at some of the common scenarios:

• Requirements are maintained in a requirements management tool (i.e., Borland’s Caliber tool, IBM’s RequisitePro, DOORS and DOORSrequireIT) – you can continue to use these tools, but you’ll probably need to spend extra time during backlog grooming, Sprint Planning, or during the Sprint. In this case, I’d only recommend pursuing this course of action if having the requirements all documented in these tools is considered to provide significant value.
• Specifications are maintained in comprehensive feature-specific artifacts/documents – just continue to use the same specifications when you transition to agile. These specifications are “comprehensive,” in that they always reflect the latest state of the product or feature.
• Specifications are written for each enhancement as it is completed – in this case, you’re doing what you would be doing if you used the backlog management tool for your documentation. And that means you probably have a very difficult time providing single-source documentation that describes your entire application. You should consider abandoning this form of specification (archive everything, of course) and move toward comprehensive documentation instead. The only decision you need to make is, do you create a baseline set of specifications first, or just build the new document as you go? The age, complexity, value in having comprehensive documentation, and degree of change in your application should drive that decision.
• No specifications exist at all – well, I guess it’s time to turn over a new leaf. Are you sure you shouldn’t have written specifications for your product? If you don’t need them, well, I guess you don’t really have a problem. However, short of an application written by a programmer for him or herself, I haven’t run into an application that didn’t benefit from some degree of specification. Here again, I’d recommend either creating a baseline set of specifications from the existing product or just starting with the next backlog item and going from there.

Bottom line, if your plan is to have good, clear documentation that describes your application (and don’t let anyone tell you that agile development means NO documentation), don’t plan on using your Product Backlog or your backlog management tool to provide that documentation. That isn’t what they are built to do, that isn’t what backlog items are supposed to do.

Good luck!