Uploaded byAhmed Misbah
Effective User Story Writing
The document discusses effective user story writing in agile development. It covers topics like what a product backlog and user stories are, how to write good user stories, acceptance criteria, and tools to help with user story development like story mapping workshops and definition of ready. The goal is to provide guidance to write clear, valuable user stories that help teams deliver the desired product functionality.
In this document
Powered by AI
Introduction to effective user story writing within the Agile framework and its importance in the product backlog.
Overview of the Agile framework, including high-level breakdown, events schedule, and daily standup meetings.
Definition and characteristics of the product backlog, its importance, and how it organizes project tasks.
Characteristics and types of product backlog items, including user stories, epics, and tasks.
Definition of user stories, their purpose in capturing user needs, and their formulation from user perspectives.
Template for writing user stories and key characteristics that make them effective including the 3 C’s and INVEST.
Checklist for user stories and comparison between user stories and tasks.
Importance of acceptance criteria in defining user requirements and ensuring a common understanding.
Phases of user story evolution including discovery, refinement, sprint activities, and reviews.
Guiding principles for effective user story writing, including importance of collaboration, defining readiness and managing dependencies.
More Related Content
Similar to Effective User Story Writing
Effective User Story Writing
- 1. Effective User StoryWriting Ahmed Misbah
- 2. Agenda 1. Quick Introduction 2.Product Backlog 3. User Stories 4. Acceptance Criteria 5. Evolution of a User Story 6. Effective User Story Writing
- 3.
- 4. Agile Framework -Overview
- 5. Agile Framework -Overview
- 6. Agile Framework –High Level Breakdown …..
- 7. Agile Framework –Events Schedule Day Event Sunday Daily Standup (internal) Monday Daily Standup Tuesday Daily Standup Wednesday Daily Standup Backlog Grooming/Bug Review Thursday Daily Standup Sunday Daily Standup (internal) Monday Daily Standup Tuesday Daily Standup Wednesday Daily Standup Backlog Grooming/Bug Review Thursday Sprint Review Sprint Retrospective Sprint Planning
- 8.
- 9. Product Backlog In thesimplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts (e.g. SRS document) https://www.scrum- institute.org/The_Scrum_Product_Backlog.php
- 10. Product Backlog (cont’d) Theagile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. https://www.mountaingoatsoftware.com/agile/ scrum/scrum-tools/product-backlog
- 11. Product Backlog (cont’d) Theproduct backlog comprises an ordered list of product requirements that a scrum team maintains for a product. These will define features, bug fixes, non- functional requirements, etc. (i.e. whatever must be done to successfully deliver a viable product). https://en.wikipedia.org/wiki/Scrum_(software_d evelopment)#Product_backlog
- 12. Product Backlog (cont’d) Theproduct backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is visible to everyone but may only be changed with the consent of the product owner, who is ultimately responsible for ordering product backlog items for the development team to choose. https://en.wikipedia.org/wiki/Scrum_(software_d evelopment)#Product_backlog
- 13. Product Backlog Characteristics 1.Only entries that add value 2. Living Document 3. Different Level of details 4. No low level tasks 5. Ordered 6. Estimated
- 14. Product Backlog Items ProductBacklog Items can range from specifications and requirements, to use cases, epics, User Stories, bugs, or timeboxed research tasks. Each PBI must have these qualities: • Description: What the goal of the PBI is. • Value: the Business Value of the PBI as determined by the Product Owner. • Estimate: the Team needs to estimate the relative effort it will take to move the PBI to Done. • Order: The Product Owner needs to prioritize PBIs by their relative value.
- 15. Product Backlog Items(cont’d) PBIs could be: • Epics • User Stories • Technical Tasks (described as User Stories) • Spikes (Knowledge acquisition or research activity) • Bugs • Any item of value to the product
- 16.
- 17. User Stories User storiesare short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. https://www.mountaingoatsoftware.com/agile/ user-stories
- 18. User Stories (cont’d) Auser story is a tool used in agile software development to capture the description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. https://www.easyagile.com/
- 19. User Story Template •Written in the following notation: – As who – I want what – So that why
- 20. User Story Template(cont’d)
- 21. User Story Characteristics– Three C’s
- 22. User Story Characteristics– INVEST
- 23.
- 24. User Story vs.Task
- 25.
- 26. Acceptance Criteria Acceptance criteriaor ‘conditions of satisfaction’ provide a detailed scope of a user’s requirements. They help the team to understand the value of the story and set expectations as to when a team should consider something done. https://www.easyagile.com/
- 27. Acceptance Criteria Goals •To clarify what the team should build before they start work • To ensure everyone has a common understanding of the problem • To help the team members know when the story is complete • To help verify the story via automated tests
- 28.
- 29.
- 30. What should acceptancecriteria include?
- 31. What acceptance criteriashouldn't include?
- 32. EVOLUTION OF AUSER STORY
- 33. Before the Sprint •Discover: User Mapping Workshop • Refinement: Definition of Ready
- 34. During the Sprint •Sprint Planning • Daily Scrum • Acceptance • Review • Backlog Grooming • Retrospective
- 35. EFFECTIVE USER STORYWRITING
- 36. Agile Manifesto Individuals andInteractions over Processes and Tools
- 37. Agile Principles 4. Businesspeople and developers must work together daily throughout the project 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 11. The best architectures, requirements, and designs emerge from self-organizing teams
- 38.
- 39. User Story Template(cont’d)
- 40. Who writes UserStories? • Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member • Note that who writes a user story is far less important than who is involved in the discussions of it • Product Owner verifies user stories
- 41. When are UserStories written? • User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project • Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone
- 42. Story Mapping Workshop •One of the key objectives of a project inception is to collect requirements collaboratively • But, many times, it is difficult to decide where to start and what to focus on • Story mapping is an engaging activity where all participants are involved in the process of building the product backlog on a wall, versus writing a dull 100-page requirement document
- 43. Story Mapping Workshop(cont’d) Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from an overarching vision. A vision is achieved via goals. Goals are reached by completing activities. And to complete an activity, users needs to perform tasks. And these tasks can be transformed into user stories for software development. Story Map Structure: Goals > Activities > Tasks > Stories
- 44. Story Mapping Workshop(cont’d)
- 45. Writing Good UserStories 1. Users come first 2. Use Personas to Discover the Right Stories 3. Create Stories Collaboratively 4. Keep your Stories Simple and Concise 5. Start with Epics 6. Refine the Stories until They are Ready 7. Add Acceptance Criteria 8. Keep your Stories Visible and Accessible 9. Don’t Solely Rely on User Stories
- 46. Dependency Structure Matrix •The Dependency Structure Matrix or Design Structure Matrix (DSM) is a simple, compact, and visual representation of a system or project in the form of a square matrix. It is a great way to visualize and manage dependencies between modules, which is critical to the management of software projects
- 47. Definition of Ready •Complete User Story with acceptance criteria • Meets 3 C’s and INVEST • Field Description table • Mockups attached to user story (wireframes in some cases) • High Level Test Cases • DSM • Workflow Diagrams