What Happens to Sprint Backlog Items at the End of a Sprint?

What happens to a Sprint Backlog Item at the end of a sprint?  Does it have no further use? Should the team just tear up the story card and throw it away?

The Manifesto for Agile Software Development recommends that agile teams should:

value working software over comprehensive documentation

Of the four values in the manifesto, this one has the greatest potential for misunderstanding.  Few people enjoy producing documentation, so many teams interpret the statement to mean “documentation not required”.  In doing so, they tend to ignore the overarching statement that qualifies all four of the manifesto’s values:

while there is value in the items on the right, we value the items on the left more

Document - Verb or Noun?

The word “document” is both a noun and a verb and it is clear that the manifesto is using “documentation” as a noun:

a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record

Teams looking for ways to eliminate a time consuming (and for them boring) task, usually have the verb “documentation” in mind.

to record (something) in written, photographic, or other form

The verb emphasises work to be done, while the the noun emphasises something we may (or may not) need.  I believe the alternative meanings lead to a lot of misunderstanding about documentation.

Everyone knows that that producing a comprehensive document takes time.  Often, a lot of this time is spent perfecting the appearance of a document.  This is time that we could spend doing more important stuff - like maybe talking to stakeholders.  

When we focus on documentation as an activity, it gives us the freedom to think about more appropriate ways of capturing what needs to be recorded.  Sometimes a photograph of a diagram on a whiteboard is sufficient. Spending hours “beautifying” the diagram using a drawing tool is probably a waste of time.

While few would actually disagree with the manifesto, there are times when our work environment demands that we document our working software maybe for governance or compliance reasons?

Can We Reuse Documentation? Reusing documentation that already exists is surely the best way to reduce the time we spend producing documentation.  We should ask ourselves the question, “is there some way we could reuse Sprint Backlog Items at the end of a sprint, rather than throwing them away?”.

Many teams populate their Product Backlogs with User Story Cards.  Story cards are “tokens” that provide a focal point for collaboration.  They remind teams that at some point, they will need to elaborate the requirements summarised on the card, by talking to subject matter experts.  What they learn during these “conversations” is often added to the back of the card as acceptance tests. Ron Jeffries neatly summarises the way story cards are used in this way with his 3C’s Card, Conversation, Confirmation [3].

The physical cards used to capture user stories are usually limited in size.  As Jeff Patton points out in his book User Story Mapping [4], it’s not long before people realise that “they’re going to need a bigger card”.   To overcome this problem, many teams use tools such as Jira [5] or Trello [6] to create “virtual cards” mirroring physical cards in the real world.  Once a team starts using software tools to manage their Product Backlogs, asking the question “what happens to a Sprint Backlog Item at the end of a sprint?” becomes even more relevant.

There is pretty much zero cost associated with retaining electronic records indefinitely.  In fact, backlog management tools such as Trello or Jira don’t really provide a way to delete items, offering the option to archive or close them instead.

Introducing the Product Inventory Once again the dictionary tells me that a backlog is:

an accumulation of uncompleted work or matters needing to be dealt with

At the end of a successful sprint, a backlog item should have been “dealt with”.  The team will have created some working software, based on the Sprint Backlog Item and as far as the sprint is concerned, the backlog item is “done” and there is no need to retain it.

But what about all the knowledge a team has acquired during the sprint?  If the team is working together well, this will have become implicit knowledge distributed throughout the team.  But what if the team’s implicit knowledge needs to be communicated to someone outside the team?  It’s probably not a good use of a team member’s time to sit for hours explaining to someone what the team did in a previous sprint.   Sometimes face to face communication is not the most efficient way.

Of course, the best place to explicitly document much of this knowledge is in the “working software” using comments directly in the program code.  But I would argue, it also worth having a real world “token” that represents the working software and serves a similar purpose to a story card.  But this token represents the “as built” implementation details of the software rather than its requirements.

What should we call “an accumulation of completed work that has been dealt with”?  “Inventory” seems like a possible choice:

A complete list of items such as property, goods in stock, or the contents of a building [8]

Rather than discarding story cards at the end of a sprint, I propose that teams reuse them to create an inventory of working software called the Product Inventory.  Over time, the Product Inventory will become a mirror image of the Product Backlog as items are gradually transferred from the Product Backlog to the Product Inventory at the end of each sprint.

The Product Inventory and Feature Teams Establishing Feature Teams [9] is considered by many to be a prerequisite for scaling agile and optimising the delivery of customer value.  Teams implementing different features all work with the same set of components which requires shared ownership of the product code.  While it will never be a substitute for documentation in the program code, the product inventory can be a useful way to get a quick overview of changes to a component made by other feature teams.

The Product Inventory and Business Rules Documenting complex business rules is a major headache for organisations developing IT solutions.  Often, business rules need to be understood and communicated throughout the organisation. Whichever approach to documenting business rules that they try, organisations quickly discover that product source code is the only place where business rules are accurately described.  Forget that “business rules document” written a few months ago - not only will it now be inaccurate but it also has the potential to actively confuse and mislead!

The product inventory provides an ideal place to document complex business rules.  This allows everyone, not just developers, to read and understand the rules. Documenting business rules in this way requires minimal effort on the part of the team, as the confirmations (acceptance tests) added to the back of the story card, already serve this purpose.  All the team needs to do, is to ensure that what is written on the card accurately reflects what the code actually does.

The Product Inventory and Change As Greger Wikstrand points out in his blog post Agile Change Requests [10], responding to change is one of the main reasons for adopting an agile approach.   If a Product Backlog Item relates to a feature that has not yet been implemented, the Product Owner can simply go ahead and make any required changes without the need to document the full history of changes.  The team is only be interested in the latest version of the item when it is ready to be included in a Sprint.

A different approach is required for changes and enhancements to features already implemented.  The Product Owner will need to add a new item to the Product Backlog describing the nature of the change.  However, when a Product Inventory has been established, it is likely there will already be an item in the inventory relating to the required change.  In this case, the item in the Product Inventory is simply moved to the Product Backlog. A major benefit of this approach is that over time, the card will accumulate a history of the changes made to the feature.

Three Backlogs - Three Inventories The Product Backlog is not the only backlog that teams work with.  Most teams also maintain an issue or “bug” backlog.  Depending on which bug tracking tool they use, items in the issue backlog normally follow a well defines life cycle starting when a new issue is raised and ending with its resolution.  Resolved issues can be thought of as an “inventory” of bug fixes in much the same way that the Product Backlog is an inventory of product features that have been implemented.  Issue tracking tools such as Jira allow resolved issues to be reopened in much the same way as I am suggesting that items will be moved from the Product Inventory to the Product Backlog when a change occurs.

In an earlier post, I described how agile teams can document non-functional requirements using a Constraint Backlog [11].  I explained how a constraint might refer to more than one backlog item meaning that it would need to be returned to the Constraint Backlog at the end of a sprint so that it could be included in future sprints.  However if a constraint has been fully satisfied during a sprint, it could be moved to a Constraint Inventory rather than returning it to the Constraint Backlog.

Implementing this vision in full would mean creating three backlogs containing:

an accumulation of features, constraints and issues needing to be dealt with

And three inventories containing:

a complete list of implemented features, satisfied constraints and resolved issues

Over time, these three inventories will develop into comprehensive documentation for the software the team have built for very little additional effort on their part.

1. agilemanifesto.org 2. en.oxforddictionaries.com/definition/document 3. ronjeffries.com/xprog/articles/expcardconversationconfirmation/ 4. jpattonassociates.com/user-story-mapping/ 5. www.atlassian.com/software/jira 6. trello.com 7. en.oxforddictionaries.com/definition/backlog 8. en.oxforddictionaries.com/definition/inventory 9. www.featureteams.org 10. www.gregerwikstrand.com/agile-change-requests/ 11. lonsdalesystems.com/post/how-can-agile-teams-capture-non-functional-requirements