Last month I wrote about Agile Requirements and a concept called GRIT or Great Requirements in Total. The idea behind GRIT is that it is important to deliver great requirements models along with great working software. GRIT recognizes that software is a product, not a project, and should be managed as a product over a product lifecycle that will involve multiple projects with many product releases. The requirements models provide stability and continuity across iterations and projects.
Agile development teams commonly rely heavily on face-to-face conversation for communication with customers and between team members. One of the principles behind the Agile Manifesto is that face-to-face conversation is the most effective method of conveying information. This focus on human interaction is one of the things that make agile development an attractive, and generally effective method of delivering working software that actually does what the product users want it to do. It also presents significant challenges as teams try to apply agile principles to the development of larger, more complex software products with teams that may be geographically dispersed across different time zones working on different components that must be integrated to form the completed product. Over a long product life cycle, face-to-face conversation may just not be possible as the people who make up the team, both customers and developers, may have changed.
Great requirements models make it possible for small, agile teams to work independently on different components or releases of a product. The teams can be separated by distance, with little chance for face-to-face communication, and still work effectively on different components of a large, complex product. Or, the teams could be separated by time, working on different releases of the product, possibly separated by years and even working on separate projects.
I recently had an opportunity to observe a team creating a requirements model that I thought showed a real understanding of the challenges of agile development of complex products and how the concept of GRIT can be applied to improve outcomes over the life of the product. The team had worked with user stories on projects in the past but felt they needed a more robust model for the complex product they are working on now. This product is expected to be in use for many years and will almost certainly have multiple upgrades and releases during that time.
The team switched from writing user stories on index cards to writing use case narratives and managing their collection of use case narratives in Excel. A true requirements management tool might be a better choice for long term management but Excel has the advantage of being widely available and pretty easy to use. The use case narratives start out as little more than user stories but they can be progressively elaborated as more details become known and alternate flows are identified. They are still pretty light weight and are easy to refine, rewrite, or refactor. The team is using the collection of use case narratives for backlog management and iteration planning. More detailed modeling and acceptance test planning is done ‘just in time’ when a use case or alternate flow is included in the scope of an iteration.
The plan is for the use case narrative model to be maintained as a long term repository of requirements in the language of the customer. Future project teams and customer representatives will be able to tap into this knowledge base when the time comes to change or upgrade the product. I like this example of GRIT in action.
