It has always been my pleasure and fun to facilitate workshops for PM (product management) community at and outside Cisco, although this was first time I did a BDD workshop with PMs alone. And I realized today how PayPal has been a really great venue for SVPMA annual product camp "unconference" for 1k+ PMs with 550 waitlisted this year! I look forward to this event every year now...huge success! Abstract: As Product Owners and Managers are driving innovation thru' those fuzzy ideas in terms of scenarios, testers have always been thinking about those in form of test cases which take form of acceptance criteria for those scenarios. When you talk about those scenarios to your teams or even peers, you see those diverging ideas converging to something concrete. That's how BDD helps you shape that idea. That fuzzy scenario, when validated thru' an engineering "spike", can be useful for product management MRD/PRD/use-case-models/stories...whatever it is that you want to use to drive product development. And this is where Agile Tester role begins! So instead of doing top-down or bottoms-up product management & testing, try this outside-in approach. Go for it! My workshop on BDD is about what I term as "Outside-in agile product management". To understand what I really mean by that, here is my slideshare presentation used rarely when teaching from the back of the class during this hyper-interactive workshop.

1. 1
Life Cycle of User Story:
Why BDD matters to PM, PO and Agile Testing?
Abstract:
As Product Owners and Managers are driving innovation thru' those fuzzy ideas in terms of scenarios, testers have
always been thinking about those in form of test cases which take form of acceptance criteria for those scenarios.
When you talk about those scenarios to your teams or even peers, you see those diverging ideas converging to
something concrete.
That's how BDD helps you shape that idea. That fuzzy scenario, when validated thru' an engineering "spike", can be
useful for product management MRD/PRD/use-case-models/stories...whatever it is that you want to use to drive
product development.
And this is where Agile Tester role begins! So instead of doing top-down or bottoms-up product management & testing,
try this outside-in approach. Go for it!
Ravi Tadwalkar
Lean/Agile/DevOps Coach
Co-founder, “Cisco Internal Coaches Network”; AgileCamp.org
Event Organizer, SVALN
June 2012. This work is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

2. 2
A User Story is a brief statement of intent
that describes something the system needs
to do for the user
“The user story is a lightweight and more
nimble substitute for what has been our
traditional means of specifying software
requirements – software requirement
specifications and use cases…”
Dean Leffingwell,
Creator of SAFe (Scaled Agile Framework)

3. 3
• Product Owner writes the
user stories with input from
customer, stakeholders,
and the team
• SME (Team member) with
domain expertise can also
write user stories
• However, it is up to the
product owner to accept
and prioritize these
potential stories into the
product backlog
• User stories focus the
work on the value defined
by the user rather than a
functional breakdown
structure
• User stories provide a
lightweight and effective
approach to managing
requirements for a system
• Details of system behavior
do not appear in the brief
statement
• 3 C’s or user stories-
card,
conversation &
confirmation
Story is written on a Card
and is groomed through
conversations between
team and product owner that
lead to confirmation about
acceptance criteria.

4. 4
• Effective communication is the key and
we need a common language
In agile development, the developer must
speak the language of the customer, not the
other way around
• The user story provides the common
language to build understanding
between the user and the technical
team
Bill Wake,
XP guru, creator of “cake slicing” technique

5. 5
• User story is not a detailed requirement
• User stories are not detailed upfront
but are elaborated just-in-time
• So they are short and easy to read
• User stories are not carried in large
unwieldy documents but are ordered lists
• User story and related code serve as
inputs to documentation
• User stories represent small increments
of valued functionality
• User stories are easy to estimate
• User stories need little/no maintenance
• User stories can be safely discarded
or archived after implementation of
“spike”

6. 6
• 2-3 sentences used to
describe intent of the story
• Summarizes intent and
represents a more detailed
requirement, whose details
remain to be determined
(which leads to…)
• Recurrent discussion
between the team,
customer, product owner,
and other stakeholders
• Attached to a user story as
notes (which solidify…)
• represent the
conditions of satisfaction
• Written as scenarios

7. 7
As a [role]
I want [feature]
so that [benefit]
Scenario 1: [scenario title]
Given [initial context]
When [event occurs]
Then [ensure some outcomes]
Scenario 2: [another scenario title]
Given [initial context]
And [another context]
When [event occurs]
Then [ensure some outcome]
And [ensure another outcome]

8. 8
As a [role]
I want [feature]
So that [value]
Acceptance Criteria
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
Notes: [discussion notes]
US.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 3
Scenario 4
Notes: [discussion notes]
US.01.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 5
Notes: [discussion notes]
US.01.02

9. 9
• Rule of thumb: get the most value with the minimum effort
Choose the split that leads to the biggest difference in value.
Choose the split that leads to the smallest difference in size
• Patterns for Decomposing
Features into user stories
1. On operation boundaries
2. On business rules
3. On effort boundary
4. On complexity
5. On data types
6. On input methods
7. On requirement type
8. On workflow boundaries
9. On engineering activity
10. On architectural boundaries
- this is your last resort,
when nothing else works!
Here are 10 examples of patterns for feature decomposition into vertically sliced user stories:
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!

10. 10
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!
Pattern Original story Split stories
Identify operational boundaries
I'd like to manipulate posts
on wiki
 I'd like to edit a post
 I'd like to share a post
 I'd like to delete a post
Identify independent business rules I'd like to search for a post
 I'd like to find posts from a specific person
 I'd like to find posts sent or received in a specific date range
 I'd like to find posts pertaining to a certain topic
 I'd like to find posts linking to a certain post
Perform what-if analysis to account for technical or
scheduling dependencies and identify an effort boundary
I'd like to see an up-to-date
contact list in chat window
 I'd like to see an up-to-date contact list in my chat window:
o need to poll server periodically
o When notifications are implemented, we can leverage API
Isolate the simple from the complex
I'd like to share knowledge
and information with others
 I'd like to quickly share mostly text and maybe a link, a-la Twitter
 I'd like to add embedded images and multimedia content to my posts
 I'd like to add references to external data to my post, updated on-the-fly
Handle various data types separately whenever possible
I'd like to ignore updates I
am not interested in
 I'd like to ignore updates from a specific person
 I'd like to ignore updates in a specific community

11. 11
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!
Pattern Original story Split stories
Provide the user with different ways to input
data into the application
I'd like the application
to help me with the list
of users I'm sharing a
post with
 I'd like to be able to pick people from a list of contacts I'm most
often in touch with
 I'd like to be able to search for people in the corporate directory
 I'd like the application to auto-complete a person's name as I
am typing it.
Separate functional and non-functional
requirements
I'd like to be able to
attach files to a post
 I'd like to be able to attach multiple files to a post. It's OK if I
have to add each one separately.
 I'd like an easy way to attach multiple files to a post. Multiple
select, drag-and-drop or any other form is acceptable so long as
I don't have to add each file separately.
Identify workflow boundaries
I'd like the system to
assist me in creating a
post
 When I add a post title, I'd like the system to look for similar
posts and give me an option to comment or edit them instead so
as to avoid effort duplication
 I'd like to link data from other posts into the post I am creating
and have the system update it automatically
Split out the research from the implementation
I'd like to configure the
application to my own
taste
 As an engineer, I need a framework to handle user preferences
so that I can make certain aspects of the application
configurable
 As a user, I'd like to be able to set user preferences in order to
configure the application the way I like it

12. 12
Work Complexity Risk Points
Small Small Small 1
Small Small Medium 2
Small Small Large 5
Small Medium Small 2
Small Medium Medium 3
Small Medium Large 5
Small Large Small 3
Small Large Medium 5
Small Large Large 8
Work Complexity Risk Points
Medium Small Small 3
Medium Small Medium 5
Medium Small Large 13
Medium Medium Small 5
Medium Medium Medium 8
Medium Medium Large 20
Medium Large Small 8
Medium Large Medium 13
Medium Large Large 20
Work Complexity Risk Points
Large Small Small 8
Large Small Medium 13
Large Small Large 20
Large Medium Small 13
Large Medium Medium 20
Large Medium Large 20
Large Large Small 20
Large Large Medium 20
Large Large Large 20
Facilitators recommend that teams should use “user story sizing board” together with
this cheat-sheet. Please pre-load the cheat-sheet with sample user stories from your
previous release, specific ones for your team. New teams can use their domain to
define what small work is for their specific context. There is “no one size fits all”.

13. 13

14. 14
• I – Independent
To schedule and implement them in any order
• Stories are valued independently meaning each story can
deliver value independently
• Strive to eliminate 0-valued technical/functional dependencies
• Eliminate dependencies by intelligently splitting stories
• N – Negotiable
Details co-created by customer & team during development
• A User Story is not a contract for specific functionality
• Flexibility through vagueness
• Lack of overly constraining and too-detailed requirements
enhances teams and businesses ability to make tradeoffs
between functionality and delivery dates
• V – Valuable
Making each vertical slice through architecture valuable to the
customer supports pay-as-you-go attitude toward infrastructure
• Create stories that are vertical slices of value to the user
• Developers often have an inclination to work on only one layer
at a time and “get it right”  WRONG BEHAVIOR
• E- Estimable
Sizing helps the customer rank & schedule story's implementation
• If a user story is too large to estimate, it should be split into smaller
stories
• If a user story is too uncertain to estimate, then a technical or
functional spike story can be used to reduce uncertainty
• Estimating user stories draws out any hidden assumptions, missing
acceptance criteria, and clarify a shared understanding of the story
• S- Small
Details can be elaborated through conversations with customer
• Small user stories provide more agility and productivity through
increased throughput and decreased complexity
• T- Testable
Decide whether goal of the story is met by writing the tests early
• Stories don’t get into an iteration if they can’t get out
• Framing stories with clear boundaries will help the team and the
business share expectations of the output and avoid big surprises

15. 15
Product Owner PO+ARCH+REP PO+QA+REP PO+Team
Product Owner
writes epic stories
that are negotiable
and has relevant
business value
Negotiable
Valuable
Independent
Small
Estimable
Testable
Architect and Team
Representative
negotiate with PO to
create vertical slices
of large stories along
architectural layers,
to shape small and
independent stories
QA ensures stories
are testable and
estimable with
scenarios for each
user story
Additional story split
along scenarios and
acceptance criteria
may occur
Team receives well
packaged user
stories
Team negotiates
user stories with the
Product Owner
Team sizes story for
understanding and
provides estimate

16. 16
Product Owner PO+Coach PO+ARCH+REP
User stories are not
properly written
Written as software
requirements,
functional specs,
horizontally sliced Coach will aid
Product Owner in
writing good user
stories
PO then journeys on
the typical user story
life cycle path
mentioned earlier
with the coach
optionally
shadowing the
meetings

17. Time to do some exercise on easel sheets-
(Remember “over 8 no collaborate”, quote from Luke Hohmann)
Let’s try this in small teams of upto 8 folks:
1. Take 1 feature/EPIC
2. Slice the cake
3. Write 1st slice as user story
4. Think of acceptance criteria
5. Write 1st acceptance criteria in english/pidgin ;-)
6. Write that same acceptance criteria using BDD template!