Agile Network India | Effective User story writing and story mapping approach | Gayatri Ganeshkumar
- 2. 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
- 3. 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
- 6. 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..
- 7. 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
- 8. Understanding Features Vs Epics Vs Story
- 9. 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
- 10. Features Vs Epics Vs Story- Illustration
- 11. 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 .
- 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 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
- 14. Product backlog to Sprint Backlog
- 15. 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?
- 16. 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
- 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. Thank you!