Presentation done at CodePalousa 2014 about gathering requirements using User Stories and Scenarios for estimation

1. AGILE
REQUIREMENTS
Amir Barylko
MavenThought Inc.

2. HIGH QUALITY
REQUIREMENTS
Amir Barylko
MavenThought Inc.

3. WHAT’S THE GOAL?
• (good
Amir Barylko
question)
MavenThought Inc.

4. TECHNIQUES
• Verbally
• Use
Cases
• Prototyping
• User
Amir Barylko
Stories
MavenThought Inc.

5. COMPLEXITY
• Task
Breakdown
• Story
points
• Planning
• Throw
Amir Barylko
poker
a dice?
MavenThought Inc.

6. PLANNING
• Gantt
Chart
• Sprints
for releases
• Continuos
• Story
•A
release
Mapping
mix of those
Amir Barylko
MavenThought Inc.

7. COMMON PROBLEMS
• (Your
Amir Barylko
input here)
MavenThought Inc.

8. CAPTURING REQUIREMENTS
User Stories
MavenThought Inc.

9. MOVIE LIBRARY SITE
Post-It
&
Sharpie!
• Context:
• Donald
likes to watch movies and tell his friends about it. He
uses a site that helps him to find movies (old, new, etc), rate
them and share with others.
• He also enjoys the previews and loves to hear when his
“favorites” movies are playing in theaters.
• Write
a list of interesting things the site could
have to provide value for someone like Donald.
User Stories
MavenThought Inc.

10. WHY USER STORIES?
• Focused
• Based
on what you expect
• Manage
• Don’t
• They
User Stories
on what not how
scope (light weight)
include many details
can be estimated
MavenThought Inc.

11. WHAT’S THE DIFFERENCE?
• Capture
• Don’t
• Only
• It
user stories (features) to fill our backlog
include any details
a vague idea of what it should do
should fit in a card
• It’s
User Stories
not a contract
MavenThought Inc.

12. PLACEHOLDER FOR
CONVERSATION
• Documents
are not a great tool for common
understanding, so we tell stories
• They
• The
spark a conversation (that’s the key)
story records/reminds of that conversation
• They
should be created with the stakeholder/
owner
User Stories
MavenThought Inc.

13. WRITING USER STORIES
User Stories
MavenThought Inc.

14. FORMAT
• As
a [ROLE], I want to [ACTION], so I can [GOAL]
Who
What
Why
As a User
I want to register the movies I’ve seen
So I can show them to my friends
User Stories
MavenThought Inc.

15. FORMAT II
• In
order to [GOAL], as a [ROLE], I want to [ACTION]
Why
Who
What
In order to show the movies I’ve seen to others
As a User
I want to register them into the catalog
User Stories
MavenThought Inc.

16. INVEST GUIDELINE
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable
User Stories
MavenThought Inc.

17. INVEST - INDEPENDENT
•
One user story should be independent of another (as much as
possible). Dependencies between stories make planning,
prioritization, and estimation much more difficult.
• As
a User, I want to see a dashboard with new
movies, my favorites and my friends movies
• As
a User, I want to see new movies
• As a User, I want to see my favorites
• As a User, I want to see my friend’s movies
User Stories
MavenThought Inc.

18. INVEST - NEGOTIABLE
•
The "Card" of the story is just a short description of the story
which do not include details. The details are worked out during
the "Conversation" phase.
• As
a User, I want to rate movies comparing director,
actors, popularity, social aspect, etc
• As
a User, I want to rate movies
• As a User, I want to include actors and directors in
the reviews
User Stories
MavenThought Inc.

19. INVEST - VALUABLE
•
Each story has to be of value to the customer (either the user or
the purchaser). One very good way of making stories valuable is
to get the customer to write them.
• As
a Developer, I want use a NoSQL db to store
movies
• As a developer I want to use Twitter Bootstrap for
the UI
• As
User Stories
a User, I want to register movies
MavenThought Inc.

20. INVEST - ESTIMABLE
•
The developers need to be able to (relative) estimate (at a
ballpark even) a user story to allow prioritization and planning of
the story.
• As
a User, I want to have the most secure site
• As
a Reviews, I want to be the only one that sees my
private reviews
User Stories
MavenThought Inc.

21. INVEST - SMALL
•
The stories should be implemented in a “small” amount of time,
otherwise they are too big and should be broken down.
• As
a User I want to get statistics about movies
• As
a User, I want to see the top 5 searched movies
User Stories
MavenThought Inc.

22. INVEST - TESTABLE
•
Each story should include the acceptance criteria that indicates the
story is implemented as expected. The owner should participate
and define this criteria.
• The
movie site should be easy to use
• Given
I am in the home page
• When I start typing in the search box
• Then
User Stories
the auto complete should help me
MavenThought Inc.

23. NON FUNCTIONAL
• How
do we write them?
• Write
tests
• Create
• If
User Stories
a checklist (should be a test)
possible, write it as story
MavenThought Inc.

24. DETAILS
• When’s
the right time to add details?
• Avoid
adding too many details until the story is
prioritized to be next
• When
doing Analysis, then the story gets defined
• Acceptance
• If
tests should be included at that point
its too big, should be split up
User Stories
MavenThought Inc.

25. MOVIE LIBRARY SITE II
Post-It
&
Sharpie!
• Rewrite
your statements as user stories using
format I or II
• As
a [ROLE], I want to [ACTION], so I can [GOAL]
• In
order to [GOAL], as a [ROLE], I want to [ACTION]
• Compare
• General
User Stories
with your team
Discussion
MavenThought Inc.

26. SCENARIOS
Scenarios & Estimation
MavenThought Inc.

27. WRITING SCENARIOS
•Each
•As
story can be described
a sequence of steps
call the alternatives in the
flow scenarios
•We
Scenarios & Estimation
MavenThought Inc.

28. COMMON LANGUAGE
•How
do we write scenarios?
•Free
form may be to confusing,
•A
tight syntax may be to restricting
Scenarios & Estimation
MavenThought Inc.

29. GHERKIN DSL
• Business
• Flush
readable DSL
out requirements
• Automated
testing
• Used
by Cucumber,
SpecFlow, jBehave
Scenarios & Estimation
MavenThought Inc.

30. SCENARIOS
Scenario: List all movies
Given I'm logged in
Step 1
And
I have (some data loaded)
Step 2
When
I (do some action)
Step 3
Then
I (should see expected results)
Step 4
Scenarios & Estimation
MavenThought Inc.

31. EXAMPLE
Scenario: Write a review for a movie
Given I'm logged in as a Critic
When
I write a review for a movie
Then
I should see the new review
in the reviews section for the movie
Scenarios & Estimation
MavenThought Inc.

32. EXAMPLE II
Scenario: See most recent movies first
Given I'm logged in as a User
When
I order the list by release date
Then
I should see the movies with the
release date most recent first
Scenarios & Estimation
MavenThought Inc.

33. EXCERCISE
•Write
•for
Post-It
&
Sharpie!
a story and scenarios
user login using
•Given,
•And,
Scenarios & Estimation
When, Then
But
MavenThought Inc.

34. GUIDELINES & GOALS
Amir Barylko
MavenThought Inc.

35. ?????
Scenario: Perfect world
Given the application is setup
When I want to use some projects
Then I should be able to load data
And
have a great user experience
but
no bugs should appear
Amir Barylko
MavenThought Inc.

36. ?????
Scenario:
Given a
And
I
When I
Then I
When I
And
I
And
I
Amir Barylko
Redirect user to originally requested page
User "dave" exists with password "secret"
am not logged in
navigate to the home page
am redirected to the login form
fill in "Username" with "dave"
fill in "Password" with "secret"
press "Login"
MavenThought Inc.

37. DESCRIPTIVE STYLE
Scenario: List all projects
Given I'm logged in
And
I have some projects stored
When
I list the projects
Then
I should see all of them
Amir Barylko
MavenThought Inc.

38. DISCOVER COMPLEXITY
• How
many scenarios per feature?
• The
more scenarios the more complex
• The
more steps the more complex
• If
scenarios are unclear, then is time to rethink the feature
Amir Barylko
MavenThought Inc.

39. DISCOVER FUNCTIONALITY
• When
is the right time to write scenarios?
• During
Inception?
• During
Analysis?
• During
Development?
• During
QA?
Amir Barylko
MavenThought Inc.

40. SCENARIO ORDER
• What
• How
• Can
happens with dependencies?
do I use data if I haven’t implemented that feature?
devs work independently in different scenarios?
Amir Barylko
MavenThought Inc.

41. VOTING APP
•In
Post-It
&
Sharpie!
teams
•Choose
top three user stories
•Write
scenarios
•Share
with the other teams
Amir Barylko
MavenThought Inc.

42. ESTIMATING
USING SCENARIOS
Scenarios & Estimation
MavenThought Inc.

43. DISCOVER FUNCTIONALITY
• When
is the right time to write scenarios?
• During
Inception?
• During
Analysis?
• During
Development?
• During
QA?
Scenarios & Estimation
MavenThought Inc.

44. ORDER MATTERS
•Can
every feature be independent?
Scenarios & Estimation
MavenThought Inc.

45. SIZE MATTERS
•Not
every story is the same size
Scenarios & Estimation
MavenThought Inc.

46. COMPLEXITY ∝ AMOUNT
7
Scenarios
6
5
4
2
1
0
Simple
Medium
Complex
WTF?
Complexity
Scenarios & Estimation
MavenThought Inc.

47. COMPLEXITY ∝ CLARITY
•Too
many steps
•Takes
more than 5 minutes to write
•You
read it the next day and have no
clue what it means
Scenarios & Estimation
MavenThought Inc.

48. RECIPE - STEP #1
Make every story around the same
size
•One
or two scenarios most
•If
more, break it down to more
stories
Scenarios & Estimation
MavenThought Inc.

49. RECIPE - STEP #2
Put a time limit (days) to each
feature
•For
example: A story has to be
completed in 1 or two days at most
Scenarios & Estimation
MavenThought Inc.

50. RECIPE - STEP #3
Choose the simplest story to
flush out requirements and
implementation
•For
example: User & password
login, OAuth will come later
Scenarios & Estimation
MavenThought Inc.

51. USER STORY MAPPING
Story Mapping
MavenThought Inc.

52. User Story Mapping is
an approach to
Organizing and
Prioritizing user stories
Story Mapping
MavenThought Inc.

53. STORY MAP VS BACKLOG
•Clearly
identifies value
•Track
finished stories
•Helps
prioritize stories
•Separate
Story Mapping
stories in releases easily
MavenThought Inc.

54. Story Mapping
MavenThought Inc.

55. Manage
Contacts
Manage
Email
Write
Email
Plain
Text
HTML
Read
Email
Basic
Render
Attachments
Delete
Email
Delete
one by
one
Create
Contact
Manage
Calendar
List
Contacts
Delete
Contact
Edit
Contact
View
Appt.
Create
Appt.
Release 1
Delete
multiple
Release 2
Markdown
Auto
Spam
Release 3
Story Mapping
MavenThought Inc.

56. User Activities
User Tasks
User Stories
Release 1
User Stories
User Stories
Story Mapping
Release 2
Release 3
MavenThought Inc.

57. Time
Priority
Release 1
Release 2
Release 3
Story Mapping
MavenThought Inc.

58. The first release
represents
the minimum viable
release
Story Mapping
MavenThought Inc.

59. BUDGET
TIME
SCOPE
Story Mapping
Fixed
Fixed
?????
MavenThought Inc.

60. Better to have
80% 100% done
Than
100% 80% done
Story Mapping
MavenThought Inc.

61. NARROWING THE GAP
Amir Barylko
MavenThought Inc.

62. ACCEPTANCE CRITERIA
• Write
the expected criteria before the
implementation starts
• Developers
will implement the feature until the
criteria is satisfied
• QA
Amir Barylko
will validate against the same criteria
MavenThought Inc.

63. BENEFITS
• Discover
• Testing
the feature
all the way
• Traceability
• Quality
Amir Barylko
every step of the process
MavenThought Inc.

64. ROLES
• Who
writes the feature?
• Who
implements the feature?
• Who
validates the feature?
• What’s
Amir Barylko
the role of QA, PM, etc?
MavenThought Inc.

65. OUTSIDE IN APPROACH
Amir Barylko
MavenThought Inc.

66. RUNNABLE FEATURES
• Features
describe functionality
• What
if we could run them?
• Then
features would validate functionality
• Becoming
Amir Barylko
live documentation
MavenThought Inc.

67. TOOLS GALORE
• Lots
of tools available that use Gherkin:
• Cucumber
/ rSpec
• jBehave
• Specflow
• Scalatest
• etc
Amir Barylko
MavenThought Inc.

68. WHERE SHOULD THEY GO?
•Acceptance
•Integration
•Unit
Amir Barylko
tests?
tests?
tests?
MavenThought Inc.

69. ACCEPTANCE TEST
•Black
box testing
•Crossing
•Should
cover all scenarios
•External
Amir Barylko
all layers
subsystems may be mocked
MavenThought Inc.

70. INTEGRATION TEST
•More
•Still
than one class
some parts can be mocked
•Partial
Amir Barylko
functionality of subsystem
MavenThought Inc.

71. UNIT TEST
• Test
for a class or method
• No
external dependencies
• Small
• Clear
Amir Barylko
MavenThought Inc.

72. TDD
• First
write a test that fails (RED)
• Write
code to make it pass (GREEN)
• Check
if code can be improved (REFACTOR)
• Start
Amir Barylko
again until it’s done
MavenThought Inc.

73. WHEN TDD IS NOT ENOUGH
•Legacy Code
•Refactoring is not viable
•Verify functionality across layers
•Validate feature end to end
Amir Barylko
MavenThought Inc.

74. DEMO
Amir Barylko
MavenThought Inc.

75. SUMMARY
Benefits
Challenges
What’s next?
Amir Barylko
MavenThought Inc.

76. BENEFITS
• Easier
planning
• Discovers
functionality
and complexity
• No
particular skill
required
• Easy Adoption
Amir Barylko
• Puts
the whole team
on the same page
• Simplifies
QA process
• Narrows
the gap
between expectations
and actual
implementation
MavenThought Inc.

77. CHALLENGES
• Different
• The
approach
roles get blurred
• Team
effort
• Others?
Amir Barylko
MavenThought Inc.

78. WHAT’S NEXT
• Take
one idea/technique that you think could be beneficial
• Use
the next four weeks to implement it
• Register
• Share
Amir Barylko
challenges, issues and results
with your peers (and with me if possible)
MavenThought Inc.

79. QUESTIONS?
Amir Barylko
MavenThought Inc.

80. RESOURCES
• Contact
me: amir@barylko.com, @abarylko
• Download: http://www.orthocoders.com/presentations
Amir Barylko
MavenThought Inc.