User stories have become an increasingly popular way for agile teams to express requirements. What teams like about working with user stories is that it shifts the emphasis from writing about requirements to talking about them. Project customers like that they are not expected to do the impossible and identify all needs upfront. Users of a product built with user stories like that the product is more likely to meet their needs than one built using a requirements technique more focused on writing than talking.
However, even though user stories cause teams and customers to talk more, there is often much that still needs to be written. Contract or outsourced development is one situation in which a team will need to augment conversations with documentation. This article will show one technique I’ve used for writing contracts to cover contracted agile development.
A few years ago, I worked on a system intended for use by broadcasters during the Summer Olympics. Sportscasters, writers and others would use the system to dredge up facts about competitors in the various events.
A sample scenario was that a sportscaster who would be covering the 400-meter hurdles later in the day would use this system to research past performance and find interesting personal facts to interject into the commentary. The system was designed as a large web of information: A user could, for
Please log in or sign up below to read the rest of the article.