What’s the Story?
From Requirements to Design
When a customer seeks a solution, stakeholders collaborate to define scope(s) and determine what the customer needs within each scope. They reach agreement on customer terminology and concepts. They break complex processes into steps, expressed in customer concepts. These are collectively known as customer requirements.
How does a purposeful architect introduce customer requirements in a meaningful way to solution designers and developers? S/he starts by writing user stories about what customer users do in the scope of the solution.
Telling a Story in a Sentence
A user story expresses a specific task a user does in the scope of a solution, and for what purpose. Although it’s called a story, it fits in one sentence. The common structure of a user story is:
“As a {person in a role}, I need to {perform a task} so that I can {fulfill a purpose}.”
Where:
{person in a role} specifies who performs the task in the context of a role they play.
{perform a task} specifies what the person will do.
{fulfill a purpose} specifies what the person performs the task for - its outcome.
Stepping Into User Stories
Mapping Out Complexity shows a process map for submitting a proposal to a customer:
A purposeful architect can express each step as a user story:
As a sales representative, I need to review an account’s request for proposal (RFP) so that I can determine if writing a proposal is worthwhile.
As a sales representative, I need to draft a proposal so that management can review it.
As a sales representative, I need to submit the draft proposal to my manager for review, so that s/he can approve it or specify changes.
As a sales representative, I need to edit the reviewed draft proposal so that management will approve it.
As a sales representative, I need to submit the approved proposal to the account to continue the sales process.
A Story’s Outcome Sets Up the Next Story
Each user story in a process assumes that the previous story produced its desired outcome. For example, the sales representative reviewing an account’s request for proposal implies s/he received an RFP from an account. Drafting a proposal assumes the sales representative determined the account’s opportunity merits writing a proposal. Story 4 suggests that the sales manager will always recommend changes to the proposal. If the sales manager returns the proposal with no changes, the sales representative can skip Story 4. Story 5 implies that management has approved the proposal, and it is ready to go to the account.
The process omits exception cases for clarity. For example, the sales representative decides not to submit a proposal in response to the RFP, or management will not approve the draft proposal. One story covers both of these cases:
As a sales representative. I need to inform the account issuing an RFP that I will not submit a proposal, so that the account knows where they stand.
What’s the Story For?
Complete, well-written user stories provide a rich context for designers and developers to understand what a customer does in the scope of the solution. A business analyst rarely reviews a user story itself with customer stakeholders. By the time s/he writes user stories, s/he has shown his/her understanding of the customer requirements.
User stories do not refer to the solution itself. Use cases deal with a user’s interaction with the solution. We’ll cover use cases in the next article.
User stories bridge discovery and design, giving solution designers and developers the big picture of what customer users do within the scope of the solution.