User stories
•Download as PPT, PDF•
0 likes•184 views
The document discusses writing user stories for agile software development. It defines what user stories and epics are, provides templates for writing user stories, and discusses characteristics like INVEST. Hands-on exercises are included where participants work in groups to write epics, stories and acceptance criteria for creating a search engine. The key points are that user stories should be small and focused on the user perspective, and writing acceptance criteria helps ensure stories meet the intended goal.
More Related Content
What's hot
What's hot (20)
Similar to User stories
Similar to User stories (20)
Recently uploaded
Recently uploaded (20)
User stories
- 1. Story writing Presented by: Tanvir Afzal
- 3. What we will achieve? • What is story and the criteria's. • Common mistake of stories. • Examples and examples. • Hands on story writing. We will enjoy and have fun together
- 5. What is story? User stories are 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.
- 6. User Stories Template User stories are often written using the following template: As a <Role>, I want <Task> so that I <Goal>
- 7. User Stories • Who are we building it for, who the user is? — As a <type of user> • What are we building, what is the intention? — I want <some goal or objective > • Why are we building it, what value it bring for the user.? — So that <benefit, value>
- 8. What Is Epic? • When a story is too large, it is called an epic. • An Epic can not be completed in a week time, or any work which will take a full sprint to complete. By observation 5-10 user stories comprise of one Epic in agile methodology. • For release planning, epics should be broken down into smaller chunks.
- 9. s
- 10. User Story Example As a customer, I want to be able to create an account so that I can see the purchases I made in the last year to help me budget for next year.
- 11. Why Write User Stories? Simply listing a set of tasks for your team, while sometimes effective, can be confusing. This can stem from a number of causes: •Vague context •Unclear expectations •Being overly technical
- 12. Characteristics Of A User Story • A story should be small enough to be coded and tested within an iteration. • We should focus on what the user is doing or getting out of the story. • The goal is that when the user story is done, the user can do something of value to them.
- 13. COS (Condition Of Satisfaction) • COS provide the Definition of Done for the story. • As details about the story evolve, capture the critical ones as acceptance criteria. • List as many acceptance criteria as possible in order to clarify the intent of the story. • Once an iteration has begun, testers can formalize acceptance criteria into acceptance tests. • By using bullet points, you can keep each criteria item brief and clear.
- 14. INVES T
- 15. INVEST • (I)ndepdendent • (N)egotiable • (V)aluable • (E)stimable • (S)mall • (T)estable
- 16. Tips to write good user stories
- 17. 1 Stories for user As its name suggests, a user story describes how a customer or user employs the product; It should be written from the user’s perspective.
- 18. 1. Stories For User (cont.) Example: "As a user I want to be able to manage ads, so that I can remove expired and erroneous ads.“ What’s Wrong With it ?
- 19. What Is Wrong Here?
- 20. Now What is wrong here? "As an commercial advertiser I want to have filtering option.”
- 21. No Acceptance Criteria or Conditions of Satisfaction • Not having COS can cause the whole chain of mistakes starting with wrong definition of development tasks or wrong estimation. • Story can failed the tests or Test Cases will cover different criteria due to lack of understanding. • Asking questions such as ‘What if … ?’, ‘Where …?’, ‘When …?’, ‘How …?’ • Use examples and simple drawings to remove assumptions
- 22. 2. Stories For Developer ‘As a commercial user I want the system to allow me run multiple searches at the same time, so that I can do my job faster.’ • Re-factor search handling mechanism to allow multiple threads for single use • Update java version to 64-bit one. Acceptance criteria need to define some measurable and testable definition of improvement like: ‘Single user can run 5 searches at the same time.’ ‘Search returns results in less than 4 seconds.’
- 23. COS Example As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork. • A user cannot submit a form without completing all the mandatory fields. • Information from the form is stored in the registrations database. • Protection against spam is working. • Payment can be made via credit card. • An acknowledgment email is sent to the user after submitting the form.
- 24. Form a group of 3 people
- 26. Please collect • Take Sticky notes • Pencil & eraser for each team
- 27. We are creating a Search Engine
- 28. Write Epics for
- 29. Epic
- 30. Lets verify the Epic
- 33. Stories? • Make DB tables to store search User data (IP and keyword) • Search keywords (Type the keyword and get result) • Result Listing. • Performance. (will find within 1 sec)
- 34. Lets verify the Stories
- 35. Write COS for stories
- 36. Lets verify COS
- 37. Why we need smaller stories? • Small stories provide focus and a short horizon for the team. • Smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code. • Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. • Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction. • Large stories increase the risk that your team will deliver nothing at the end of the iteration.
- 38. Reference: • http://www.yodiz.com/blog/writing-user-stories-examples-and-templates-in-agile-methodologies/ • http://www.agilemodeling.com/artifacts/userStory.htm • https://medium.com/@rachid/3-common-user-story-mistakes-2cb2d14b5061#.ob95zxhi0 • https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing- user-stories • http://www.yodiz.com/blog/writing-user-stories-examples-and-templates-in-agile-methodologies/ • http://www.boost.co.nz/blog/2010/09/acceptance-criteria/ • http://www.yodiz.com/blog/what-is-epic-in-agile-methodology-definition-and-template-of-epic/
- 39. Any Questions?
Editor's Notes
- Independent - We want to be able to develop in any sequence. Negotiable - Avoid too much detail, keep them flexible so the team can adjust how much of the story to implement. Valuable - Users or customers get some value from the story. Estimable - The team must be able to use them for planning. Small - Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration. Testable - Document acceptance criteria, or the definition of done for the story, which lead to test cases.
- If you don’t know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas—but not on data and empirical evidence.
- This case what is missing is persona or role mentioned. At the first glance you don’t see any issues with that User Story, because all the required elements are present. Now tell me who is the user for whom you are going to build that feature of ads management and what does he understand ads management? Is that a portal administrator, who wants to have possibly of database clean-up and ads moderation? Or maybe it is an advertiser, who wants to have list of all ads he submitted to the side and have possibility of removing ads when they are not needed any longer or there was error found in the content? As you may noticed, I mentioned only two different roles with different expectations from the system. I this case what is missing is persona or role mentioned.
- No Business Value or Benefit for Customer We have the role, we have the need, but reason and business value are missing. Why does an commercial advertiser want to have filtering option? What does he want to achieve?
- This typical example of Story for a Technical Backlog or technical requirement representation. Sometimes User Stories like this one are also part of so called technical debt. Technical debt consists of necessary maintenance tasks like software updates, re-factoring, changing frameworks and so on. They are totally rightful to be implemented, but represented like in the example above they do not represent value for the customer and you will not get a buy-in from Product Owner. Also from the ‘agile point of view’, you need to deliver a business value at the end of every iteration and the team needs to be able to present it to the stakeholders on the review meeting. How to write such a story correctly? Rewrite it from a user point of view with persona on role. Example: ‘As a commercial user I want the system to allow me run multiple searches at the same time, so that I can do my job faster.’ Task to go with it can be: ‘Re-factor search handling mechanism to allow multiple threads for single user.’, ‘Update java version to 64-bit one.’ Acceptance criteria need to define some measurable and testable definition of improvement like: ‘Single user can run 5 searches at the same time.’ and ‘Search returns results in less than 4 seconds.’
- Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story. When you still have development to test handoffs (i.e. before you start doing ATDD(Acceptance Test Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code. Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt. Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something! Large stories increase the risk that your team will deliver nothing at the end of the iteration. Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.