Agile Requirements - Page 3

Rachel Davies, Agile Experience Ltd, UK, http://www.agilexp.com

Cards

A document is both a communication medium and a storage mechanism. Although a conversation provides us with a rich communication medium, the words may be lost in the ether with no record except in the memories of the participants. During team planning workshops, XP teams use index cards to make notes about stories being discussed. There is no formal form for a story card; it can be written in any way that is useful (although a short name for the story as a heading helps). These cards are used after the weekly planning session to create a visible plan on the wall. Each day the team holds a meeting around the plan to review the work remaining for the week. It’s possible that a few days may elapse before I start work implementing a story but because the team sit together I can replay the conversation with them before I start work.

Agile software development is not a series of mini-waterfalls. The notes on index cards are not the counterparts of requirements documents; this is a different process model. There are several tools available for managing electronic story cards – that seem to miss the point that the story card description is not a requirements document in the traditional sense and treat these as the prime artefact rather than the story tests. Index cards provide a non-intrusive way of documenting a conversation without disrupting the flow. The cards are not a simple input from which a conversation is generated; they are also an output of the conversation. A story card is not a stand-alone document describing the full requirement it is really a brief note that a token that to remind us of key details from a conversation. Our primary source of information during the development is conversation, made possible by co-locating the team.

The return to handwriting on cards appears to be a retrograde step. Surely, people in the software industry should be using the latest software tools for planning? To understand why index cards are preferred for planning with stories, you need to understand that paper has different "affordances" – interactions that it supports – and limitations. For example, spatial layout – it is easy to shuffle tasks written on index cards around to create different layouts. When planning it helps to review prioritization from different perspectives – by risk, by value, etc. Another affordance is visibility - it is easier for a group of people to read index cards spread out on a table than gather around a computer screen. Index cards can be annotated by grabbing a pen. Grabbing the keyboard in a meeting usually means changing seats. I have worked with teams who have used data projectors in meetings to make the computer screen visible to all but what happens is the group end up waiting for the operator to keep up with them. The way we interact with today’s planning software slows down the meeting dynamics. If we are to use software tools then we need to review how they support group interaction and to remember, rrecording the conversations is a secondary activity, we don’t want it to disrupt the primary activity understanding the desires around the system.

Index cards have some limitations too. If your meeting group is large then some may not be able to read the text on the card. I encourage teams to "write big" using marker pens and move to using sticky-notes on a wall rather than a table if members of the team have problems.

It’s worth remembering that the drive for a "paperless" office [6] was motivated by the drive to reduce storage costs of large quantities of data - to remove paper records in filing cabinets. Index cards don’t hold a lot of data and can be easily bundled with a rubber band. The notes on the index card are a temporary holder of the requirement. The cards are only used for the purpose of planning; the cards are not intended to become a lasting record. Index cards can be thrown away after they have been translated into acceptance test scripts and committed to version control.

Confirmation

The first task in implementing any story is to create a set of automated system-level tests that clarify the scope of the story. These tests are used to confirm the story has been implemented as expected. These tests remove ambiguity by creating executable tests capturing examples of how business rules should fire.

In 2002, Ward Cunningham published the Fit framework [7] this provides a way for business users to write story tests using desktop tools such as MS Word and Excel. When using a test framework like Fit, tests are typically worked on by a customer-developer pair, fleshing out scenarios to be implemented as part of the story.

The great thing about these tests is that non-technical people can read them and so become living documents that specify the system behaviour and also check that the system continues to support the full suite of stories developed to date. In agile software development it is these customer level story tests that form the requirements repository.

Summary

The software industry has been stuck in an illusion that dry language is less ambiguous and that facts can be isolated from the context and the needs of the business driving the development of a software system. Requirements can be documented in an ivory tower of analysis before engaging with technical labourers who will be building the monumental system. Agile teams have learned that limited abstract ideas ought not to be frozen at the start of software development but need to be refined and explored within an iterative development process.

In agile software development, the sharing of stories binds the team together, as the storyteller offers up their ideas they are woven into the system. People show their interest by asking questions and sharing insights. Suddenly, everyone starts to feel like an equal partner in a project that they are engaged in together. Traditional barriers between departments fall away and people feel energised to make the possibilities discussed a reality.

References

1. Agile Manifesto ­ http://www.agilemanifesto.org
2. "Serious Play: How the World's Best Companies Simulate to Innovate" by Michael Schrage Harvard Business School Press (1999) ISBN: 0875848141
3. "Agile and Iterative Development" by Craig Larman - Addison Wesley (2003) ISBN: 0131111558
4. "Extreme Programming Explained" 2nd edition by Kent Beck, Cynthia Andres - Addison Wesley (2004) ISBN: 0321278658
5. "Essential XP: Card, Conversation, Confirmation" by Ron Jeffries [http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
6. "The Myth of the Paperless Office" by A.Sellen, R.Harper - The MIT Press (2003) ISBN: 026269283X
7. "Fit for Developing Software" by Rick Mugdrige, Ward Cunningham - Prentice Hall (2004) ISBN: 0321269349

---

Methods & Tools requirements articles

• Non-Functional Requirements: Do User Stories Really Help?
• Automated Acceptance Tests and Requirements Traceability

More Agile and Scrum Knowledge

Scrum Expert

Agile Videos

---

Page 2    Click here to view the complete list of archived articles

This article was originally published in the Fall 2005 issue of Methods & Tools