StoryProcess

Jim'sPages => Story Process

Background

These pages describe the "story driven" process style adopted by my team in 2002. I first wrote them as a proposal to the team. I sold the concept, coached the team through some internal practice, and introduced the process to our customers. I recently rewrote the pages as documentation of a running process and posted them here.

Before the new emphasis on stories, we had a pretty solid traditional RUP style, revolving around use cases, requirements and Rational tools. It was working quite well, but a few mutations along the way showed promise in a more fine-grained approach. So here we are.

Some of the ideas come from XP and other AgileMethodologies. But we are careful to not say we are "doing XP." XP has 12 (or so) major practices, and we are trying only a few.

See AgileMethodologies for references to more information on agile development.

Story Driven

The biggest new concept for the team was a Story. A story is:

A promise to have a conversation. The conversation is the kind of analysis interview or dialog we have always done. The record of the conversation is in a UseCase.
The unit of development & deployment. Small units of work are critical to iterative development. Developers should be able to implement a story in 2-4 weeks. A story may break into several tasks for several developers.

Every change to the system is a story. A new scenario for a major release is a story. A defect fix is a story. An enhancement is a story. A missed requirement is a story (when it is found.) A technical improvement - say adding a database index - is a story. All stories go through exactly the same PlanningGame and implementation process.

Stories are transitory. Once a story is implemented the story artifacts can disappear.

Process Overview

The process involves familiar steps and deliverables with a few changes ...

Activity	Deliverables	Notes
Business Analysis	Business Case: Needs	The Business Case describes the problem or opportunity and how a new electronic system would improve the situation. Includes ROI.
Visioning	Vision: Features	The Vision describes the System Under Discussion in terms of goals, scope, features.
Scoping	Stories Acceptance Tests Estimates UC Catalog	Customers and IT develop the story list. Developers make a first level estimate and optional task list on each story. Analysts and developers map stories to use cases.
Planning	Detailed Stories Project Plan IterationPlan Tasks	The Project Plan specifies how many releases are planned, and the number of iterations for the next release. The Iteration Plan allocates stories to iterations, and assigns resources for the next iteration or two.
Analysis	UseCases Requirements AnalysisObjectModel LogicalDataModel AcceptanceTestsRefined	Analysis is done on a per story basis, using the promised conversation. The use case is the record of that conversation. Acceptance tests are refined from brief descriptions to more formal specs.
Design	Implementation Doc Models	As today ...
Construction	Code Unit Tests	As today ...
Testing	AcceptanceTests	Acceptance tests are implemented & executed.

Scoping & Planning

These were shown above as two activities. In practice, they should be done together in a single PlanningGame session.

Roles, Responsibilities, Rights

There are three major TeamRoles in this process - Customer, Manager and Programmer - each with responsibilities and rights. (Of course there are other job descriptions, but they all roll up into these roles.) The Customer drives by deciding what is important and why. The Programmer signs up for tasks and does them. The Manager works with the others to lay out work plans, track work against the plans and communicate the results.

Managing the Project

Iteration planning is the core of planning code development. The initial PlanningGame session gives us a good roadmap for the full duration of the project. But the contents of each iteration are likely to change frequently as business priorities change, defects and missing requirements are found, new stories crop up. To avoid wasting effort, we recommend planning only the next one or two iterations in any detail beyond the list of stories.

Requisite Pro is central to managing.

When stories are identified, put them in ReqPro as requirements with type Story.
When requirements are added to a use case & ReqPro, add traceability to the story.
Give developers stories to work on.
As they progress, they check off requirements as READY FOR TEST.
When all requirements are TESTED, a story is done.
When all stories in an iteration are TESTED, the iteration is ready.

Documents, Requirements & Stories

Requirements are discovered by having conversations about Stories. Stories are related to requirements in ReqPro by traceability, not parentage.

Stories and Requirements have a many-to-many relationship. A story spawns many requirements, and a requirement might satisfy parts of more than one story. We expect the latter to be far less common.

As requirements are discovered, they are recorded in Use Cases or Design Docs. Each requirement has only one parent document.

Stories are also units of implementation which become one or more tasks. When all requirements pass tests, the story is done. After the iteration containing a story passes all tests, story artifacts are no longer interesting and may be removed.