The objective of this article is to help business analysts capture functional requirements for an information system as User Stories. It discusses four levels of story. The first two levels represent business context. Levels three and four involve functional detail needed by developers and testers to deliver stories at those levels.
NOTE: This article assumes the reader is familiar with basic Agile concepts of product owner, user, the user story form “As a … / I want … / So That …”, and story refinement conversations.
The terms Epic and/or Feature are variously used in different Agile practices to represent the ‘higher levels’ of user stories. To avoid any confusion from that inconsistently-applied terminology, this article uses generic level numbering to indicate stories at each of the four levels being discussed.
Those levels represent:
L1 – Business Process User
L2 – Process Activity
L3 – Information System Capability
L4 – Capability Subset
L1 – Business Process User
A story at Level 1 identifies a user (person role, group, organization, or other system) participating in a business process. (See article A Functional View from 10,000 Feet.) An L1 story indicates that the product owner intends that type of user to have new or changed support from an information system when performing one or more of the process’s activities.
Figure 1 – Business Process Example
The following is an example of an L1 user story of an Online Shopper involved in the Online Purchasing business process, as depicted in Figure 1:
"As an Online Shopper I want to be able to purchase products online so that I don't have to travel to a store location."
Refinement of an L1 story should involve the product owner and/or process-specific subject matter experts (SMEs). Output from the refinement conversation is some number of L2 user stories. Each represents a process activity the user performs that the product owner wants supported by an information system.
L2 – Process Activity
A story at Level 2 identifies a user involved in a specific process activity. Ideally there is an L1 story that provides the process context for the activity. Each L2 story represents the product owner’s intension that there be support for that activity provided by an information system.
The following is an example of an L2 user story (within context of the L1 example):
“As an online shopper I want to be able to shop for products I intend to purchase so that I can place an order for them.”
Refinement of an L2 story should involve the product owner and/or activity-specific SMEs. Output from the refinement conversation should be one or more L3 stories.
NOTE: An information system provides support to users through five fundamental capability types:
- User Interface - supports a user interacting with the system in real time.
- Report – provides a snapshot of system information to a user, readable by a person offline.
- Data Import – supports the system receiving information provided by a user in machine-readable form.
- Export Data – provides a snapshot of system information to a user in machine-readable form, intended to be readable by an application or other system.
- Automated Function – allows an information system, using information it has access to, to perform a process activity without user involvement.
Which capability type(s) are wanted to support a given process activity is the product owner’s decision, ideally made during L2 story refinement. The following scenarios should be considered when creating capability-specific L3 stories to support an L2 story’s process activity:
Involves external information source – Is the activity best supported by manual data entry via a user interface? Is there a source of machine-readable data that can be imported? Is there need or justification for having both capabilities?
Involves referencing system information – Is the user best served by being able to access the information in real time? As a report? As an exported file? Is there need or justification for having two or all three capabilities?
Involves creating information using existing information – Should a user interface be provided that supports a person performing the activity? If it’s possible for the system to perform the activity without user involvement, does the product owner want the system to have that capability? Is there need or justification for having both capabilities?
An L3 user story should be created for each capability type the product owner believes has sufficient value. The system context diagram in Figure 2 shows functional capabilities supporting users. L3 user stories representing each were created during refinement conversations of L2 stories representing the first three process activities in Figure 1.
Figure 2 – Sales Information System Context Diagram
NOTE: Unrefined L2 user stories can be used to support evaluating packaged software solutions. Each story represents a process activity the product owner wants supported by an information system. It’s up to each software vendor to identify how capable their solution is in supporting those activities. If shortlisted, the vendor should be able to demonstrate those capabilities.
L3 – Information System Capability
A story at Level 3 represents a software capability, of one of the five fundamental types listed above, addressing a whole process activity. (See article Keeping High-Level Requirements High-Level.)
The following is an example of an L3 user story (within context of the L2 example):
“As an online shopper I want to be able to shop online for products I intend to purchase so that I can place an order for them.”
The refinement conversation about an L3 story should involve the product owner and/or activity-specific SMEs, along with members of the delivery team. The objective of the conversation is to come to a mutual understanding of the capability, plus identify details about its individual data, label, and action-triggering elements. These details, plus any supporting diagrams, mock-ups, etc., are added to the L3 story under the heading of Acceptance Criteria.
NOTE: Complete examples of element-level detail for each of the five fundamental capability types can be found in the Trips-R-You Web-based Flight Booking Case Study and discussed in the webinar Minimum Detailed Requirements, Maximum Requirement Detail).
During L3 user story refinement additional support capabilities may be identified. For example, during the conversation about an L3 report capability user story, a need may be identified for a user interface capability to support report users running the report on an ad hoc basis.
Each support capability identified should be represented by its own L3 story and associated with the context L2 story. Each will require its own refinement conversation.
L4 – Capability Subset
A story at Level 4 represents a business-meaningful subset of an information system capability’s element-level details. Ideally there is an L3 story that provides context for the subset. An L4 story is created either to contain elements split-off from an L3 story not yet delivered, or elements representing an addition or change to an existing (i.e., delivered) capability.
The following is an example of an L4 user story (within the context of the L3 example):
“As an online shopper I want the option to “save for later” products I don’t want to purchase right now so that they are available for future purchases.”
The refinement conversation about an L4 story should involve the same people, and level of detail, as its context L3 story. In the case of elements being split off, those details should already be defined as part of the acceptance criteria originally documented during the L3 story refinement conversation. In the case of additions or changes to an existing capability, the L4 refinement conversation is about the changes wanted.
Each L4 story should be associated with the context L3 story. Not only will the L4 story acceptance criteria need to be tested, but the whole L3 capability should be regression tested.
Functional Requirements as User Stories
The stated objective of this article was to help business analysts capture functional requirements for an information system as User Stories. Four levels of user story have been discussed, each having a specific context, purpose, and story refinement output.
L1 – Business Process User – Within the context of a business process, a user involved in the process is to be supported by an information system. Story refinement output is some number of L2 stories.
L2 – Process Activity – Within the context of a user involved in a business process, a process activity is to be supported by an information system. Story refinement output is some number of L3 stories.
L3 – Information System Capability – Within the context of a process activity, a capability of one of the five fundamental capability types supporting the information involved in that activity is to be delivered. Story refinement output is acceptance criteria data, label, and action-triggering element-level details.
L4 – A capability subset – Within the context of a capability, a business-meaningful group of data, label, and action-triggering elements are to be delivered. Story refinement output is the subset of acceptance criteria detail relevant to the capability addition or change.
Given the above generically-named levels of user stories, it’s left to the reader to translate the concepts each represents to the equivalent terms used within their Agile practice.
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].