What is the reason doing requirements the Agile way provides more value

1. GATEWAY TO AGILE
Agile Requirements

2. GERVAIS, NATE, MOOGSOFT, PANEL
Ø Gervais Johnson, MATRIX, Director of National
Agile Practice, Empower Agile Adoptions,
Transitions and Transformations, 16 Years IBM
tenure / Agile Founding Member, 31 years of
implementing solutions and solving problems
Ø Rob Trivetti, Over 8+ years experience
managing complex, high priority, cross-
functional and time-sensitive programs for
Agile transformations, financial, social media,
eCommerce, SAAS and telecom companies.
PANEL: Larry Apke, Ron Lichty, Arun Ramanna, Andrew Grutza, Nate VanDusen

3. • 33 Years IT Solutions
Experience
• Privately-held, $240M
• Top25 in the U.S
• National Firm with 12 officesacross
the U.S.
• Offshore Servicesin India via Joint
Venture
• Nearshore Services in Monterey
Mexico via Joint Venture
MATRIX
Nearshore Delivery
Center: Monterey Mexico
• Provide IT Solutions to U.S. companies and assist IT Professionals with their careers.
• Solutions Practice successfully delivered 900+ projects for over 230 different clients.
• Flexible Solutions Delivery Models – Onsite, Offshore, Nearshore, Hybrid
• 75+ Recruiters company-wide, plus 30 Offshore Recruiters
• 1500+ MATRIX Consultants on staff.

4. GATEWAY TO AGILE ROADMAP

5. DECONSTRUCTING
REQUIREMENTS
Agile Ecosystem Thread #4

6. Innovation /
Product Discovery
Requirements
Agile
Deconstruction
Workshop/Debrief
Next Event
OUR
AGENDA

7. AGILE ECOSYSTEM
Product
Discovery:
Design Thinking
and Lean UX
Thread

8. HISTORICAL REQUIREMENT PROBLEM
8
Extensive upfront requirements problems
• The Requirements Document itself becomes a
goal (BRD, SRD, etc)
• Inaccuracies of written language,
misinterpretation
• Maintaining requirements for changes
• User sign-off on massive requirements,
renegotiation
• Too detailed, too soon
• Lack of clarity about user groups
• Frequent changes disrupts progress
• Difficult to communicate changes

9. REQUIREMENTS AND VALUE
9
• Historically, over 60% of
methods are rarely if ever used
and 20% are always or o:en
used.
• Agile focuses teams and
organiza?ons on delivering
what is of value, not more of
what will rarely or never be
used.
• Agile also focuses on an
economic view of all work.
7%
13%
16%
19%
45% Always
O:en
*The Standish Group – CHAOS Study 2002

10. AGILE REQUIREMENT HISTORY

11. AGILE REQUIREMENT FRAMEWORKS

12. AGILE REQUIREMENT HIERARCHY

13. AGILE ATOMIC REQUIREMENT

14. PERSONAS AND ROLES FOR CUSTOMER EMPATHY
14
• By thinking in terms of roles, every
feature built will be used by
someone, solve some business
problem
• Allows the team to get inside the
head of the user - to think of the
system from the user’s POV
• Helps determine the most useful
features in the system
• Tells a story
• Easy to determine when we are
‘done’.

15. STORIES: THE ATOMIC WORK FOR THE TEAM
15
• The Requirements Problem
• User Story Defined
• Different User Story Types
• Three C’s
• Sliced Vertically
• “I.N.V.E.S.T.”
• Tips for Writing Good Stories
• Increasing Levels of Granularity
• Value and Estimation

16. USER STORY GOODNESS
16
• Narrative texts that describe an interaction
of the user and the system
• Focus on the value a user gains from the
system
• Written in a language that conveys what
our customers want/need
• Metaphor for the work being done
• Not a highly documented requirement,
want to gain understanding through first-
hand communication
• From an Agile Development standpoint,
reminder for collaboration and just-in-time
definition
• Specifically and purposely non-formal
• Evolves iteratively

17. USER STORY: 3 C’S
17
• Card – Token representing the request. Notes (description) are
captured to reflect details towards implementation, priority and
cost.
• Conversation – Represents the request communicated from
customer to team (through PO). Deeper definition should done be
through collaborative refinement.
• Confirmation – Acceptance make it possible to understand what
needs to be done to complete the request.
Title: “As a <role>, I want <something> so that <benefit>”

18. USER STORY CONSTRUCT: THE APPLICATION CAKE
18
Test
Design
API
GUI
Business Logic
Database
User Story #1
User Story #2
User Story #3
Vertical Stack End to End

19. USER STORY DEFINITION OF DONE
19

20. ACCEPTANCE CRITERIA IS CRITICAL

21. USER STORY TIPS
21
1. Start with the users
2. Use personas to discover the right stories
3. Write stories collaboratively
4. Keep stories simple and concise
5. Start with epics
6. Decompose (or break down) stories until they
are ready
7. Start with paper cards
8. Keep stories visible and accessible

22. REQUIREMENT DECOMPOSITION
22
1h
2H
7h
Idea
Refinement
Execution
Increasing Level of
Granularity
• Epics and features contain
the big idea and enough to
get a rough estimate
• User Stories can be
created/refined from Epics
and features closer to
execution
• Tasks created at planning
before execution
Estimation Tools:
T-Shirt Sizes
Story Points
Task Hours

23. REQUIREMENT HIERARCHY
23
• Epics are large stories that describe the project vision at a high
level
• Too big to work in a single sprint or release
• Not small enough to work as-is
• Enough detail to roughly estimate and prioritize, but not too
much
• Have to be disaggregated/decomposed in order to be worked
• Features are subsets of epics that focus in a valuable piece of an
epic
• Small enough to be completed in a release but not a sprint
• Prioritized and estimated (roughly) to set the content of a release
• Only a subset may be important
• User Stories are business-driven requests that are:
• Independent, yet together make up a feature
• Small enough to be completed in a sprint (multiple)
• Can have dependencies, but shouldn’t be interdependent
• Prioritized and estimated to set the content of a sprint

24. IMPACT DETERMINATION

25. TIME IS IMPORTANT
25
When you think about it When we can work on
Epic Feature User Story Task
Feature User Story
User Story
Task
Task
Task
Task
• Big idea
• Placeholder
• Suppor?ng the vision
• Can span Mul?ple
releases
• Possibly mul?ple
teams
• Workflow based
• Priori?zed against
other features
• Usually one or more
per release
• Possibly mul?ple
teams
• Small, Independent
• Represent
conversa?on to
have
• More than one per
sprint
• Single Team

26. CONTEXTUAL VIEW: STORY MAPPING
26
Feature 3 Feature 1 Feature 4 Feature 2
Usage Sequence
Arrange features or
ac?vi?es in the order
they are done.
Feature 3 Feature 1 Feature 4 Feature 2
Usage Sequence
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Iden?fy stories that
support features or
ac?vi?es
Epic Epic

27. RELEASE AND MVP VIEW: STORY MAPPING
27
Feature 3 Feature 1 Feature 4 Feature 2
Usage Sequence
Feature 3 Feature 1 Feature 4 Feature 2
Usage Sequence
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Less Important More important
Arrange stories so most
necessary are at the top
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Pick necessary stories that
are required for a first
release
Epic Epic

28. EPIC/FEATURE/USER STORY MAPPING
28

29. STORY MAP EXAMPLE (PART 1)
29

30. STORY MAP EXAMPLE (PART 2)
30

31. STORY MAP EXAMPLE (PART 3)
31

32. STORY MAP TO KANBAN TRANSITION
32

33. WORKSHOP TEAMS

34. POWER START
• P = Purpose
• O = Outcome
• W = WIIFM
• E = Energize and Engage
• R = Roles/Responsibilities

35. WORKSHOP DEBRIEF
Experiences
Wow Moments
Feelings
Follow-up

36. PANEL
Ask me About Agile Requirements

37. GATEWAY TO AGILE
Deconstructing Requirements Next

38. AGILE ECOSYSTEM
Product Discovery and
Product Delivery Success
Depends on Harmonious
Alignment of the Agile
EcoSystem

39. DARK AGILE PATTERNS
Technocentrics
Self-Absorbed
Augmented Reality
Laissez-Faire Grand Unified Theory

40. TECHNOCENTRICS
Too much Focus on
Agile Practices and
Tools
Individual Collective
(Limited) Interior

41. SELF-ABSORBED
Too much Focus on
Agile Practices and
Tools + Agile Humanity
All Individual Interior

42. AUGMENTED REALITY
Little or No Focus on
Organization and
Culture & Environment
Individual Collective
(Selective) Interior

43. LAISSEZ-FAIRE
Insufficient Focus or
Alignment Across
Quadrants
Individual + Collective
Interior + Exterior
Minimalist

44. GRAND UNIFIED THEORY
Too Much Focus on
Each Quadrants, No
Synchronicity
Individual + Collective
Interior + Exterior
Extermist

45. GATEWAY TO AGILE
Roadmap and Interests Groups

46. ROADMAP
Estimating

47. GRAND CHALLENGE
2018 Team to organize and
operate grand challenge
Prize $TBD

48. EVENT COORDINATION
Team to help with
Meetup and
Events

49. SPONSOR MANAGEMENT
Team to help with
Sponsors

50. THANK YOU
NEXT: Agile Estimating