Agenda
Get a high-level view of story mapping, how to create features and epics, release planning
and key concepts to understand how stories work and how they come to life in Agile a
story’s lifecycle.
Example of effective Agile scrum User story.
Key Takeaways:
• Creating stories collaboratively.
• Learn how to convert stories to a working software
• User story vs Use Case
• Flat backlog vs story map
• Technical vs functional stories
Identify your first release –slice out the release roadmap
• What features should anchor the
next release?
• Intention of the release slice vs
Expected Target outcomes.
• Arriving at an incremental release
strategy.
• Arriving at the Release Roadmap
• MVR-Minimum viable release
Story Mapping –Discovery
outcome
Story
mapping
personas
Lifecycle of a story
• Who they are for?
‒ Type of User and a sentence or two about him/her.
• What problems are we solving and build it.
‒ Type of activities people would use the product for.
• What we are imagining?
‒ Stop at each of the user story and ask what are the specific things they would
do here.
‒ What are the alternative things they could do
‒ What would make it cool.
‒ What about when things go wrong?
• What will happen when you build it?
‒ The big story and the details that describe the software we build.
‒ Assumptions and Solutions
• Priority
• Outcome/Product Goals
• Minimize the amount of build
• There will always be more to
build than we have time and
money for.
• Minimize the output and
Maximize outcome and
Impact.
• ‘Now’ Vs ‘Not Now’
• Watch the dev cycle spend
• When trying to get the big
picture get to the end of the
story before getting lost in
the details.
Things to Remember..
Feature prioritization Model
Differentiator Spoiler
Cost Reducer Table stakes
The MVP Rant..
• Minimum viable product –’That version of a new
feature which allows the team to collect the
maximum amount of validated learning about
customers with the least effort’ or in short the
‘Smallest feature that’s useful and creates value’
• Remember…What's minimum to one customer/user
isn’t to another one
Understanding Features Vs Epics Vs Story
Features Vs Epics Vs Story- Differences
Type of
Information
Epic Feature Story
Description
Bold, Impactful,
marketable
differentiators
Short, descriptive, value
delivery and benefit
oriented statement.
Customer and marketing
understandable.
Small atomic. Fit for
team and detailed user
understanding
Responsibility
Program and
product
management,
business analysts,
business unit
managers
Product Manager and
Product Owner.
Product Owner and
Team.
Time frame &
Sizing
6-12
months.
Sized in
points.
Fits in an
internal
release
(PSI) ,
divide into
incrementa
l sub-
features as
necessary.
Sized in
points.
Fits in a
single
iteration.
Sized in
story points.
Testable No Yes Yes
Features Vs Epics Vs Story- Illustration
User Story Vs Use Case
The User story focus is on who the feature is for, what they want to
accomplish, and why rather than what system can do.
• User Needs
• Focus on customer value
• Easy for Users ,stakeholders and scrum teams
• As a < type of user ,role>, I want to <function,some goal> so that
<benefit,why,reason,value>
Use Case is a set of interactions between a system and one or more actors, with
actors being people, other systems, or both. It’s a complete specification of all
possible scenarios. They are usually created as documents, and generally include
this kind of information:
• About behavior Build in the system
• Focus on perspective of the user and their interaction with the system.
• Highly detailed description of behavior of the user and system .
User story checklist
•Independent – User Stories should be as
independent as possible.
•Negotiable – User Stories are not a contract. They
are not detailed specifications. They are reminders of
features for the team to discuss and collaborate to
clarify the details near the time of development.
•Valuable – User Stories should be valuable to the
user (or owner) of the solution. They should be
written in user language. They should be
functionality/feature, not tasks.
•Estimable – User Stories need to be possible to
estimate. They need to provide enough information
to estimate, without being too detailed.
•Small – User Stories should be small. Not too small.
But not too big.
•Testable – User Stories need to be worded in a way
that is testable, i.e. not too subjective and to provide
clear details of how the User Story will be tested.
User story checklist
Acceptance Criteria
Acceptance criteria is a detail description of system or
feature put forward by the product owner, it’s a criterion
against which the user story should be validated and
tested.
What Acceptance criteria should include..
•Negative scenarios of the functionality.
•The impact of a user story to other features.
•UX concerns
•Functional and non-functional use cases
•Performance concerns and guidelines.
•What system/feature intend to do
•Doesn’t do anything, isn’t supposed to do
•End-to-end user flow
What Agile Acceptance Criteria Should Not Include
Do not include following obvious stuff as your acceptance
criteria for your user stories
•Code Review was done
•Non-blocker or major issues
•Performance testing performed
•Acceptance and functional testing done
Above checklist need to be included as part of DoD
(definition of done), which serve as a checklist for overall
sprint process, those shouldn’t be part of acceptance
criteria
Product backlog to Sprint Backlog
Shortcomings of a Flat Product Backlog
Shortcomings of a Flat Product Backlog
•The flat backlog makes it impossible to discover
the ‘backbone’ of your product — the customers
interaction experience with the product
•Arranging user stories in the order they’ll be
delivered doesn’t help a product manager explain
to others what the system does
•The flat backlog provides no context or ‘big
picture’ around the work a team is doing
•A flat backlog makes it hard for the product
manager to determine if they’ve identified the
relevant user stories
•Release planning is difficult with a flat backlog.
How do you prioritise what to build first in an
endless laundry list?
Shortcomings of a Flat Product Backlog and why story maps..
What A User Story Map Achieves that a Flat Product
Backlog Can’t
•Focus on Desired Customer Outcomes: the visualization
of the customer journey allows teams to identify and
implement features based on customer outcomes, and
track progress at a glance against a story map
•Bring the Customer Journey to Life: the transformation
of the flat product backlog to a customer centric story
map means teams have a better understanding of their
customer journey and what their customers want and
value
•Prioritizing Actions Based on Value to the
Customer: visualization of the customer journey allows
teams to prioritize work based on “value to customer”,
resulting in better outcomes and less waste
References
• https://www.azuredevopslabs.com/
• https://www.sep.com/sep-blog/2009/10/19/new-approaches-to-risk-management/
• https://uxknowledgebase.com/story-mapping-part-1-e65b0b74591
• https://scalingsoftwareagility.wordpress.com/2009/01/14/agile-enterprise-requirements-information-model-6b-%E2%80%93-subset-for-
portfolio-management-epic/
• https://aspetraining.com/resources/blog/use-case-2-0-perfect-solution-to-your-agile-requirements-problem
• The Definitive Guide ,Jacobson 2011
• User story Mapping –Discover the whole story build the right product –Jeff Patton and Peter economy
• https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-methodologies/
• https://www.visual-paradigm.com/scrum/what-is-product-backlog-in-scrum/
• https://marketplace.atlassian.com/apps/1212078/easy-agile-user-story-maps-for-jira?hosting=cloud&tab=overview
• https://blog.easyagile.com/the-difference-between-a-flat-product-backlog-and-a-user-story-map-93cff02f23a3
Thank you!

Agile Network India | Effective User story writing and story mapping approach

  • 2.
    Agenda Get a high-levelview of story mapping, how to create features and epics, release planning and key concepts to understand how stories work and how they come to life in Agile a story’s lifecycle. Example of effective Agile scrum User story. Key Takeaways: • Creating stories collaboratively. • Learn how to convert stories to a working software • User story vs Use Case • Flat backlog vs story map • Technical vs functional stories
  • 3.
    Identify your firstrelease –slice out the release roadmap • What features should anchor the next release? • Intention of the release slice vs Expected Target outcomes. • Arriving at an incremental release strategy. • Arriving at the Release Roadmap • MVR-Minimum viable release
  • 4.
  • 6.
    Lifecycle of astory • Who they are for? ‒ Type of User and a sentence or two about him/her. • What problems are we solving and build it. ‒ Type of activities people would use the product for. • What we are imagining? ‒ Stop at each of the user story and ask what are the specific things they would do here. ‒ What are the alternative things they could do ‒ What would make it cool. ‒ What about when things go wrong? • What will happen when you build it? ‒ The big story and the details that describe the software we build. ‒ Assumptions and Solutions • Priority • Outcome/Product Goals • Minimize the amount of build • There will always be more to build than we have time and money for. • Minimize the output and Maximize outcome and Impact. • ‘Now’ Vs ‘Not Now’ • Watch the dev cycle spend • When trying to get the big picture get to the end of the story before getting lost in the details. Things to Remember..
  • 7.
    Feature prioritization Model DifferentiatorSpoiler Cost Reducer Table stakes The MVP Rant.. • Minimum viable product –’That version of a new feature which allows the team to collect the maximum amount of validated learning about customers with the least effort’ or in short the ‘Smallest feature that’s useful and creates value’ • Remember…What's minimum to one customer/user isn’t to another one
  • 8.
  • 9.
    Features Vs EpicsVs Story- Differences Type of Information Epic Feature Story Description Bold, Impactful, marketable differentiators Short, descriptive, value delivery and benefit oriented statement. Customer and marketing understandable. Small atomic. Fit for team and detailed user understanding Responsibility Program and product management, business analysts, business unit managers Product Manager and Product Owner. Product Owner and Team. Time frame & Sizing 6-12 months. Sized in points. Fits in an internal release (PSI) , divide into incrementa l sub- features as necessary. Sized in points. Fits in a single iteration. Sized in story points. Testable No Yes Yes
  • 10.
    Features Vs EpicsVs Story- Illustration
  • 11.
    User Story VsUse Case The User story focus is on who the feature is for, what they want to accomplish, and why rather than what system can do. • User Needs • Focus on customer value • Easy for Users ,stakeholders and scrum teams • As a < type of user ,role>, I want to <function,some goal> so that <benefit,why,reason,value> Use Case is a set of interactions between a system and one or more actors, with actors being people, other systems, or both. It’s a complete specification of all possible scenarios. They are usually created as documents, and generally include this kind of information: • About behavior Build in the system • Focus on perspective of the user and their interaction with the system. • Highly detailed description of behavior of the user and system .
  • 12.
    User story checklist •Independent– User Stories should be as independent as possible. •Negotiable – User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development. •Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be functionality/feature, not tasks. •Estimable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed. •Small – User Stories should be small. Not too small. But not too big. •Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
  • 13.
    User story checklist AcceptanceCriteria Acceptance criteria is a detail description of system or feature put forward by the product owner, it’s a criterion against which the user story should be validated and tested. What Acceptance criteria should include.. •Negative scenarios of the functionality. •The impact of a user story to other features. •UX concerns •Functional and non-functional use cases •Performance concerns and guidelines. •What system/feature intend to do •Doesn’t do anything, isn’t supposed to do •End-to-end user flow What Agile Acceptance Criteria Should Not Include Do not include following obvious stuff as your acceptance criteria for your user stories •Code Review was done •Non-blocker or major issues •Performance testing performed •Acceptance and functional testing done Above checklist need to be included as part of DoD (definition of done), which serve as a checklist for overall sprint process, those shouldn’t be part of acceptance criteria
  • 14.
    Product backlog toSprint Backlog
  • 15.
    Shortcomings of aFlat Product Backlog Shortcomings of a Flat Product Backlog •The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product •Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does •The flat backlog provides no context or ‘big picture’ around the work a team is doing •A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories •Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?
  • 16.
    Shortcomings of aFlat Product Backlog and why story maps.. What A User Story Map Achieves that a Flat Product Backlog Can’t •Focus on Desired Customer Outcomes: the visualization of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map •Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value •Prioritizing Actions Based on Value to the Customer: visualization of the customer journey allows teams to prioritize work based on “value to customer”, resulting in better outcomes and less waste
  • 17.
    References • https://www.azuredevopslabs.com/ • https://www.sep.com/sep-blog/2009/10/19/new-approaches-to-risk-management/ •https://uxknowledgebase.com/story-mapping-part-1-e65b0b74591 • https://scalingsoftwareagility.wordpress.com/2009/01/14/agile-enterprise-requirements-information-model-6b-%E2%80%93-subset-for- portfolio-management-epic/ • https://aspetraining.com/resources/blog/use-case-2-0-perfect-solution-to-your-agile-requirements-problem • The Definitive Guide ,Jacobson 2011 • User story Mapping –Discover the whole story build the right product –Jeff Patton and Peter economy • https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-methodologies/ • https://www.visual-paradigm.com/scrum/what-is-product-backlog-in-scrum/ • https://marketplace.atlassian.com/apps/1212078/easy-agile-user-story-maps-for-jira?hosting=cloud&tab=overview • https://blog.easyagile.com/the-difference-between-a-flat-product-backlog-and-a-user-story-map-93cff02f23a3
  • 18.