How Do Story Cards Enable Agile Development?

Story cards specify the automated system capabilities that are desired by the business community, and represent the major point of communication between that side and the software delivery team.

Editor's note: This is the second in a series of three articles by Joel Collamer focusing on agile software development, exclusive to InsuranceTech.com. Read the first installment, What Agile Development Really Means. This installment provides an overview of story cards.

Story cards are typical artifacts utilized in an agile software development process to specify the automated system capabilities that are desired by the business community. Story cards should be easy-to-understand, “lightweight” artifacts, that fully support a short-interval (e.g. 2 weeks), iterative software development process.

Story cards are an antidote to the problem of “heavyweight” business requirements specifications, which are usually voluminous and quite unintelligible to the business community. The story cards represent the major point of communication between the business community and the software delivery team. They are intended to be easily understandable by virtually any member of the business community, and yet contain enough information for the lead software developer(s) to estimate the work effort and identify delivery risks.

A story card represents a specific business requirement, typically a small-business functional component, which is estimated by the software development team to take less than 2 weeks (usually much less) of work effort for a pair of software developers. Many agile practitioners follow a particular wording pattern for their story card titles, as follows:

As an [Actor’s Name] I need a [Desired Business Capability] to achieve [Intended Business Outcome]

A story card insurance example from a recent client follows this pattern:

STORY CARD

As an underwriter, I need an ability to view the underlying in-force auto and home policies, the coverage forms and then have an ability to select the desired umbrella limit from available options and calculate the resulting umbrella premium based on current approved rates.

The software developers envision this capability, then prepare a preliminary work estimate. If the estimate is more than two weeks, then the story card needs to be divided into two or more story cards.

The story cards typically originate during an up front “planning game” where business stakeholders identify their future state high-level business requirements. Usually the “planning game” is a facilitated session where the business stakeholders map out the future state business processes that are planned for automation and identify the specific business system capabilities that will be needed. Each desired system capability becomes the title of one story card. The planning game deliverable is an inventory of these “business/system capabilities” (story card titles), and the list of story card titles is sometimes referred to as a story catalog or product backlog.

Once the story cards are identified, the lead software developer(s) conducts a software delivery risk assessment and preliminary work estimate for each story card. If the software delivery lead identifies any areas of design or delivery risk, they have the option to introduce technical only story cards, which are designed specifically for the software delivery team so that time can be allocated to investigate any delivery risks and determine risk mitigation approaches.

The story card backlog then undergoes a joint prioritization with the product owner(s) and the lead software developer(s), who assign each story card to a software delivery release plan. The prioritization process is a facilitated negotiation between the product owner(s) who is looking for business functionality, as quickly as possible, and the software delivery lead(s), who is looking to minimize and mitigate delivery risks. The intention is to make the product owner fully aware of any anticipated delivery risks. Then the product owner(s) and the delivery lead(s) jointly move story cards carrying delivery risk to earlier iterations so that they are explored as early as possible. Once the story card list is prioritized, the business product owner(s) and the lead software developer(s) agree on a release plan. The product owner identifies a set of iterations that when complete represents a usable unit of business functionality that would be ready for release to the production environment. After that plan is complete, the story catalog is ready for the software delivery cycle to begin.

During each iteration cycle, the story cards that have been assigned to that iteration undergo further analysis by a business analyst(s) who works closely with the product owner(s) and members of the business stakeholder community who have a solid detailed understanding of what specifically is needed to support the business. Details for each story card are collected by the business analyst for data requirements, screen flows and user acceptance criteria. The story card acceptance criteria form the basis for automated test-driven development. In general, the story card must have these yes/no criteria. The acceptance criteria can be incorporated into the automated test plans for the resulting business component.

A well developed and completed business story card has the following characteristics:

Derived from the needs of the business community (Usually resulting from an upfront planning game).
Has a title that is readily understandable to the business community and contains enough detail and/or examples so that the business analyst can readily initiate a discussion with the business community.
Contains the name of the actor(s) who will use the resulting business component
Upon delivery into production provides something of business value to the business community
Estimated to take less than two weeks of work effort (usually much less) for a pair of programmers (Able to be completed within a single iteration cycle)
Contains user “acceptance criteria” which specifies the criteria by which the business community will gauge whether the component meets their business requirements needs.