User stories are only the start.
While they are helpful in identifying valuable feature increments, they require more precision for implementation.
And specifying the “What” is complex without a shared structure that can be systematically used along the software lifecycle.
That’s where the two methods of Behavior-Driven Development and Example mapping can be leveraged to create Quality Engineering User Stories.
This repeatable methodology supports the implementation of User Stories that can scale with the Quality Engineering maturity of your organization.
Follow the QE Unit for more Quality Engineering from the community.
What is a Quality Engineering User Story?
User stories were mainly formalized in eXtreme Programming (XP) and became more popular with agile development methodologies.
The initial goal of user stories is to decompose the work in valuable feature increments (i.e. stories) to share on the expected behavior before implementation.
The thing is that implementation leads to questions like:
- What are the nominal and error cases?
- Which examples can help to align and refine stories?
- How to capitalize on a user story for testing and observability?
Quality Engineering User Story answers these points being the combination of:
- User Story
- Example Mapping
- Behavior Driven Development (BDD) Scenarios
The collaborative exercise results in formally written specifications that can be executed and integrated later on with, for instance, test automation.
User Story
Rachel Davies in the 2000s proposed a formal template to increase the efficiency of user stories specifying role, feature and benefits, which became a standard.
One essential point is the necessary collaboration between the actors on user stories. Using the 3 amigos is one possibility to align end-to-end stakeholders.
Example Mapping
Example mapping is a technique to collaboratively align the understanding, refine acceptance criteria and the granularity of users stories through examples.
Its main value is to help identify the domain boundaries of a user story, challenge underlying assumptions and align the expected outcomes through examples.
A picture is worth a thousand words. An example is worth a million.
Behavior-Driven Development Scenarios
BDD then comes, enabling to specify the different “What” through a repeatable structure of scenarios in a Given / When / Then format.
The first added-value of this combination is to align the most important scenarios, formalize the examples and related acceptance criteria in a shared format.
Once written, you are also all set to implement testing methodologies such as Acceptance Test–Driven Development (ATDD), or Specification by Example (SBE).
That’s where a user story becomes a Quality Engineering User Story, being from the start designed to scale with the software maturity of the organization.
Why using Quality Engineering User Story?
Companies have an increasing pressure of digital reinvention through software to survive in a digital ecosystem where both speed and scale of innovation are required.
In such a context, business performance depends on the capability of organizations to continuously deliver software with Quality and Speed.
That’s where companies need Quality Engineering, the paradigm constraining the entire software lifecycle to Quality at Speed software.
It’s not enough to use an Agile methodology with User Stories—software increments must be delivered at a high-standard with a capability to scale.
How Quality Engineering User Story contributes to Quality?
User stories are good at cutting down a backlog into valuable feature increments, but they lack precision in the scenarios and acceptance criteria.
In addition to the traditional user story, the use of BDD scenarios and Example Mapping in Quality Engineering User Story structures much stronger software requirements.
Performed collaboratively, the methodology can be performed transversally with a few actors that can iterate from user stories to detailed behaviors, embeddable in different tests.
Quality Engineering User Story contributes to Quality being:
- Result-oriented on essential scenarios, examples and acceptance criteria
- Systematic applicable to each backlog item leveraging Scrum and DoR
- Scalable by being replicable across teams and Continuous Testing methods.
How Quality Engineering User Story contributes to Speed?
Speed in Quality Engineering is about delivering fast software increments in the short-term, as well as keeping that velocity in the long-term, with more complexity.
User stories first support a rhythm of iteration breaking the backlog into actionable features that help to focus on short-term valuable milestones.
The addition of BDD and Example Mapping improve standard user stories directly specifying scenarios and acceptance criterias to accelerate with minimal reworks.
Quality Engineering User Story contributes to Speed with:
- Focus on the main user scenarios that reduce the time-to-market
- Rhythm in breaking down larger objectives into smaller user stories
- Asynchronicity with a written process that can scale across teams
- Visibility relying on formalized templates easily shareable between teams.
How to start with Quality Engineering User Story
The Quality Engineering User Story methodology relies on a series of systematic steps to perform collaboratively in short cycles.
Indeed, the following guidelines are fundamental:
- Ensure a transversal collaboration
- Formalization must follow the template
- Stories must be precise and with an end-user
- Explicit the “why” giving the context
- Specify the “what”, not the “how”
From there, the following iterative steps can be performed from a backlog:
- Breakdown backlog into actionable User Stories
- Challenge the story with Example Mapping
- Specify scenarios with acceptance criteria using BDD
Breakdown backlog into actionable User Stories
Whether you are using an Agile methodology, you will have a set of features and tasks (i.e. product backlog) to split into smaller tasks to actually deliver them on-time.
The question that arises is “Where to split?” and “Which to start with?”
The breakdown and prioritization of the backlog requires to:
- Organize in logical blocks your backlog, not by priority
- Breakdown items on the user perspective, identifying valuable increments
- Make a regroupment of increments by similarity of behavior in user stories
- Estimates the stories with a code (story points, t-shirt size, avoiding days)
- Order the backlog by value and minimal implementation effort
- If items are still too large, perform the same process again.
This exercise will let you with a set of actionable user stories items you can then start to precise with the 3C model: Card, Conversation, Confirmation.
The result of this exercise is what is called a User Story Map structuring your stories.
Some people would argue to already split the user stories again by path, vertical or horizontal slice. It’s better to first refine what is expected before doing such work.
Challenge the story with Example Mapping
Example Mapping is a useful technique to collaboratively detail a user story, finding alternative paths, new scenarios, or error cases.
The exercise must be time-boxed in 25 minutes per story to extract the essential value in the minimal time available (that’s one example to constrain to Quality at Speed).
The structure of an example mapping board uses four colors:
- Yellow for the story on top
- Blue for rules about behavior
- Green for examples of rules
- Red for questions arising during the exercise.
The process then iterate through each box by:
- Select a story
- Write the business rules
- Identify rules examples, preferably in gherkin style
- Write questions or doubts as they arise.
Now that the perimeter of the story has been clarified among the actors, it is then time to effectively formalize for effective implementation and testing phases.
Specify scenarios with acceptance criteria using BDD
Behavior-Driven Development focuses on explaining the behavior on fine-grained stories, reinforcing the need for our previous exercise of splitting.
The format relies on 5 elements to systematically specify:
- Feature in scope
- Scenario expliciting the case
- Given defines the set of conditions
- When clarify the action trigger
- Then describes the expected results.
You can start such a methodology only by writing them associated with your story, in your documentation portal for example.
A better alternative is to version your user story BDD files, allowing you to easily share, revert and later on, use them for acceptance criteria.
As a result, your breakdown of user stories with example mapping will have clear behavior defined for each scenario, accelerating your implementation with quality.
Quality Engineering User Story within MAMOS
Implementing Quality Engineering User Story is an effective method to start with Quality at Speed software limiting the adherences with other improvements.
You can gradually deploy the practice among teams that rely on Kanban, Scrumban or Scrum processes with different levels of maturity in DoR and test automation for instance.
It’s a kind of Minimum Viable Move allowing you to deliver a continuous flow of Minimum Viable Feature supporting the reinvention of your digital offerings.
With the increasing complexity and maturity of your organization, you can leverage extend the combination to Customer Journey Maps, Continuous Testing, among others.
We can hardly predict the future, but we can be ready for it with Quality Engineering. It’s a question of everyday discipline and choices.
How will you specify your next User Story?
References
Jeff Patton (2014), User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media.
Dean Leffingwell (2011), Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
Mike Cohn (2005), Agile Estimating and Planning and User Stories Applied, Pearson.
Mike Cohn (2004), User Stories Applied: For Agile Software Development, Addison-Wesley.
John Ferguson Smart (2014), BDD in Action: Behavior-driven development for the whole software lifecycle, Manning.