The rationale

A lot is lost in the transmission of technical details
It is easy to develop a product that does not help the user or the company.
In discussing details, the value is often forgotten
IT and Business are prone to domain specific jargon that hinders understanding.

Story mapping

Frame the problem. Who is it for, and why are we building it?
Map the big picture. Focus on breadth, not depth. Start with mapping the world as it is today, including pains and joys of users.
Explore. Talk about other types of users and people, how else they might do things, and the kinds of things that can go wrong. Sketch, prototype, test, and refine solution ideas while refining the map.
Slice out a release strategy. Focus on what you’re trying to achieve for the business, and on the people the product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals.
Slice out a learning strategy. Use the map and discussion to help you find your biggest risks. Slice the map into even smaller minimum viable product experiments that you can release to a subset of users to learn what’s really valuable to them.
Slice out a development strategy. Slice your minimum viable solution into the parts you’d like to build earlier and later. Focus on building things early that help uncover technical issues and development risks sooner.

Frame the idea

Use these discussions to review

why your business is building the software,
who it’s for, and
how you’ll measure success.

Named business problems you’re addressing
Specific business metrics affected
Short lists of specific customers and users
Metrics that will allow us to measure whether people use and like this new feature
Big risks and assumptions
Discussions with business stakeholders and subject matter experts

Understanding customers and users

Lists of specific user roles and their needs
Simple user profiles or person sketches
Simple organizational profiles or personas
Story maps about how people do things today—also known as journey maps
User feedback, research and observations are needed to fill in the unknowns

Building the story

Think — Write — Explain — Place

Write down a few words about your idea on a card or sticky note about your idea immediately.
Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories.
Place the card or sticky into a shared workspace where everyone can see, point to, add to, and move it around.

Color coded cards/Notes

Yellow (Story Card): A single User Story which is a typical starting point for discussion.
Blue (Rule Card): acceptance criteria placed beneath the yellow story card.
Green (Example Card): examples that illustrate a rule
Red (Question Card): questions that arise during discussion, to be placed as appropriate

Rearrange into a cohesive story

Discussion for each step of the user story

What are the specific things they’d do here?
What are alternative things they could do?
What would make it really cool?
What about when things go wrong?

Arrange and discuss the information

Arrange the associated activities

Envision solutions

Focus on specific customers and users,
Envision solutions that will help them.
Visualize solutions with words and pictures.
Validate those solutions with customers and users.

Story maps
Use cases and user scenarios
UI sketches and storyboards
UI prototypes
Architectural and technical design sketches
Architectural or technical prototypes
collaboration with team members, users, customers, stakeholders, and subject matter experts

Sorting through ideas

Focus on Big idea

What is the big idea?
Who are the customers? Who are the companies we think would buy the product?
Who are the users? Who are the types of people inside those companies we think would use the product, and what would they be using it for?
Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it?
Why are we building it? If we build this product and it’s successful, how does that help us?

High priority ideas

Differentiator: A feature that set them apart from their competition
Spoiler: A feature that is moving in on someone else’s differentiator
Cost reducer: A feature that reduces the organization costs
Table stakes: A feature necessary to compete in the marketplace

Mapping the story into an action plan

Frame the problem. Who is it for, and why are we building it?
Map the big picture. Focus on breadth, not depth. Map the world as it is today, including the pains and joys.
Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can go wrong.
Slice out a release strategy. Focus on what the business is trying to achieve, and on the people the product will serve. Slice away everything not needed to reveal minimum solutions that both delights the customers and help your organization reach its goals.
Slice out a learning strategy. The minimum viable solution serves as a hypothesis to be tested. Create smaller minimum viable product experiments that can demonstrate what’s really valuable.
Slice out a development strategy. Sliced away everything not needed. Further slice your minimum viable solution into the parts needed to be build earlier from those needed later. The focus is on building early things that highlight technical issues and development risks sooner.

Improving user stories with examples

Pains: Things that don’t work, parts people hate
Joys or rewards: The fun things, the things that make it worth doing
Questions: Why do people do this? What’s going on when they do?
Ideas: Things people could do, that would take away pain, or make the joys even better

Design Goal of the Minimum Viable Product

Adjust the Story maps to discover the core principles
Identify a small, viable solution that has value
Estimate a budget and time schedule for delivering this prototype.
Create plan for development and testing with minimize risk.

Good ideas will address the important issues

Test the information gathered

Reaffirm consenus

Get feedback from individuals in the group

Strategic story mapping

Opening game: Focus on the essential features or user steps that cross through the entire product. Focus on things that are technically challenging or risky. Skip the optional things users might do and sophisticated business rules needed before release. Build enough to see the product working end-to-end.
Midgame: Fill in and round out features. Add in stuff that supports optional steps users might take and implement those tough business rules. Search end-to-end for things that would effect performance, scalability, and usability.
Endgame: Refine the release, improve the user experience, and efficiency. Apply real data and scale, operations and implement suggestions from user feedback

Feature User Story Template

Feature [name]
As a [type of user]
I want to [do something]
So that I can [get some benefit]

Who:
What:
Why:

The BDD Process

User story: starting point for every upcoming change to a system
Discovery: Discuss concrete examples of the new functionality to explore, discover and agree on the work to be done
Formulation: document those examples in a way that can be automated, and check for agreement.
Automation: implement the behaviour of each documented example using an automated test to guide the development of the code.

Basic Cucumber Operation

Feature File Definition

Feature − Name of the feature under test.

Description (optional) − Describe about feature under test.

Scenario − What is the test scenario.

Given − Prerequisite before the test steps get executed.

When − Specific condition which should match in order to execute the next step.

Then − What should happen if the condition mentioned in WHEN is satisfied.

The Cucumber Process

Multilingual support in Cucumber

cucumber –i18n-languages : lists all available language version
cucumber –i18n-keywords th : list all keywords for the target language
cucumber

Thai keywords

Keyword	Thai keyword
feature	“โครงหลัก”, “ความต้องการทางธุรกิจ”, “ความสามารถ”
background	“แนวคิด”
scenario	“เหตุการณ์”
scenario_outline	“สรุปเหตุการณ์”, “โครงสร้างของเหตุการณ์”
examples	“ชุดของตัวอย่าง”, “ชุดของเหตุการณ์”
given	“*”, “กำหนดให้”
when	“*”, “เมื่อ”
then	“*”, “ดังนั้น”
and	“*”, “และ”
but	“*”, “แต่”
given (code)	“กำหนดให้”
when (code)	“เมื่อ”
then (code)	“ดังนั้น”
and (code)	“และ”
but (code)	“แต่”

Feature and Scenarios

Compare numbers
  I choose too small a number ✓
  I choose too large a number ✓
  I choose the exact number ✓

play hi-low
  I decline playing again ✓
  I try playing again ✓
  I choose the exact number ✓
  I play a full game ✓
  I play a full game ✓
  I play a full game ✓
  I play a full game ✓
  I play a full game ✓
  I play a full game ✓

Check for bad guesses
  I enter a large number ✓
  I enter a negative number ✓
  I enter a non-numeric guess ✓

21 scenarios (21 passed)
115 steps (115 passed)
0m0.116s

CS 340: BDD

Behavior Driven Development