User stories in agile software development


Published on

Theoretical basics how User Stories are used in agile software development

Published in: Education, Technology, Business
1 Comment
  • Being successful at binary options trading does not mean that you will not suffer some losses. Rather, it means that you will be able to strike a decent winning ratio. Want to earn legit money from binary options trading? My recommendation is GINO SHEARER SYSTEM software for hassle free trading with frequent winning signals.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User stories in agile software development

  1. 1. User stories in agile software development Prepared by: Sandra Svanidzaitė & Eglė Kumpelytė
  2. 2. Agile background for stories • • • • The Agile Manifesto Communication PDCA - Plan, Do, Check, Act Why, What & How
  3. 3. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Source:
  4. 4. Project Management is all about communication People who want IT must communicate with people who can build IT.
  5. 5. Effective communication
  6. 6. PDCA - Plan, Do, Check, Act
  7. 7. Why, What & How • • • • WHY are we doing this? Voice of the stakeholder (Stakeholders) WHAT needs to be done? Voice of the user (Product Owner, Subject Matter Expert) • HOW do we build it? • Voice of the developer (Agile Team)
  8. 8. Agile User Stories • Work breakdown structure (WBS) in traditional vs. agile projects • What is a user story? – – – – – Cards - Conversation – Confirmation INVEST guideline Story forms/templates Skill levels regarding user stories of an Individual and Agile Team Non-functional Requirements gathering • User Story writing workshops, techniques and concerns – – – – • • • • • User Role Modeling Trawling for Requirements User Proxies Epics and user story breakdown User Stories vs. Use Cases vs. Requirements Requirements IEEE 830 Product Backlog of User Stories Tips for Writing Good User Stories Smelly User Stories
  9. 9. Alternative to Work Breakdown Structure (WBS)
  10. 10. What is a User Story? • User Stories provide a light-weight approach to managing requirements for a system. • A short statement of function captured on an index card and/or in a tool. • The details are figured out in future conversations between the team and the product owner or customers. • This approach facilitates just in time requirements gathering, analysis and design by the following activities: – Slicing user stories down in release planning – Tasking user stories out in sprint planning – Specifying acceptance test criteria for user stories early in development
  11. 11. Why User Stories are so Good? • • • • • • Understood equally well by everyone Useful for iteration planning Great for iterative development Encourage deferring of details Support opportunistic design Emphasize verbal communication
  12. 12. The 3 C's
  13. 13. What is a Story Card? • Short description of user or customer valued functionality. • The visible part of a story, which is followed by conversations between the customer and the project team and confirmation of acceptance criteria. – The customer team writes the story cards because they are in the best position to express the desired features and because they must later be able to work out story details with developers and to prioritize the stories. – The customer team includes those who ensure that the software will meet the needs of its intended users. This may include testers, product manager, real users and interaction designers.
  14. 14. User Story - INVEST guideline
  15. 15. User Story - INVEST guideline
  16. 16. User Story-INVEST guideline
  17. 17. User Story - INVEST guideline
  18. 18. User Story- INVEST guideline
  19. 19. User Story - INVEST guideline
  20. 20. Story form/template I As a < role > I want < activity > so that < business value > • Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity. • Activity – represents the action to be performed by the system. • Business Value – represents the value to the business. Why is this story important?
  21. 21. Story form/template I • The "role – activity – business value" template is one of the most commonly recommended aids for teams and product owners starting to write user stories. As a bank customer I want to withdraw money from an ATM So that I’m not constrained by opening hours or lines at the teller’s
  22. 22. User Story form/template I "As a < role >, I want < goal/desire > so that <benefit> " As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work.
  23. 23. User Story form/template II "As a < role >, I want < goal/desire > " so that <benefit> can be optional As a non-administrative user, I want to search for my customers by their first and last names.
  24. 24. User Story form/template III "In order to < receive benefit > as a < role >, I want < goal/desire > " In order commissions would be calculated differently to each agency, as I accountant I want system to allow me to set up these values manualy in commisions tab
  25. 25. User Story form/template IV "As < who > < when > < where >, I want <what> because < why >" As a accountant who is managing policy commisions, I want commisions to be calculated, because we need use different rates for different aggencies
  26. 26. Acceptance/Validation criteria • • • • like stories it's written in simple language define the conditions of success/satisfaction provide clear user story boundaries remove ambiguity by forcing the team to think through how a feature or piece of functionality will work from the user’s perspective • establish the basis for acceptance testing – steps to test the story (given-when-then scenarios)
  27. 27. Acceptance Test form/template The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story: (Given) some context (When) some action is carried out (Then) a particular set of observable consequences should be obtained Given my bank account is in credit, When I attempt to withdraw an amount less than my card’s limit, Then the withdrawal should complete without errors or warnings
  28. 28. Skill levels of Agile Team An Agile team will benefit if the skills that underpin effective use of user stories are widely distributed among the team. – It is likely that people with background in "requirements analysis" or with a history in "analyst" roles will have a leg up in acquiring these skills.
  29. 29. Skill Levels of an Agile Team • Beginners – the team is able to obtain, "just in time", the information necessary to implement user stories, for instance by having access to the product owner or domain expert • Intermediates – the team formalizes all activity as work on user stories, each team member can answer at any moment the question "what user story are you working on at the moment“ • Advanced – at any moment, any member of the team can answer the question "what is the most important user story in the backlog, and why"
  30. 30. Skill levels of an Individual Contributor • Beginner – able to illustrate a user story with an example (including user’s goal, existing context, user’s actions and expected outcomes) • Intermediate – knows or can identify the relevant user roles and populations and refers to them appropriately in user stories • Advanced – can assess a user story using the INVEST checklist or an equivalent, and rephrase or split the user story as necessary
  31. 31. Non-Functional Requirements Do User Stories Really Help? • Agile teams focus on identifying User Facing Features in the form of User Stories that can form the basis of incremental deliveries. – Business Analysts work closely with stakeholders to understand what user stories must be satisfied by the product that they are developing. • A flaw in this approach can be that users don’t mention non-functional requirements (NFRs) and developers don’t push to understand what quality attributes the software should satisfy.
  32. 32. Consider Non-functional Requirements from the Start Most software systems are in use for many more times longer than they take to build. So you need: • Start conversations about the operating environment and user expectations early. • Talk about the quality capabilities of the system, like performance and security, at the start of the project. • Hold a session with the team to brainstorm risks to consider what are the things that can go wrong once the system is live?
  33. 33. Types of Non-functional Requirements Basically, non-functional requirements relate to qualities of the system that cut across user facing features, such as availability, efficiency, flexibility, portability, security, performance, reliability, reusability, robustness, scalability, usability. —However, these requirements do affect the function of the system and it is possible to design tests that these qualities are present.
  34. 34. The difference from functional requirements • The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature.  Alternative terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements".
  35. 35. NFRs Can be Grouped Into • Execution qualities, such as performance and usability, which are observable at run time. • Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system. Agile teams need to consider both categories of NFRs so how do we ensure that these don’t get missed?
  36. 36. Who should have take responsibility? • When asked for user stories, stakeholders often forget to mention the NFR assuming that these will simply be there. Unfortunately, the agile team cannot telepathically know what the business needs and when pressure seems to be about delivering features consideration of NFRs gets neglected.
  37. 37. Agile Team should Take Responsibility "Many development teams don't grasp the fact that accountability for getting the requirements (all the requirements) right falls to them." Dave Nicolette • An agile team has to take a more proactive role regarding requirements. – User stories are not simply mini-requirements specifications that are handed over to development fully formed. – Writing stories on cards is a very interactive process that involves the technical team asking questions about acceptance criteria that includes NFR. We must take responsibility for flushing out NFRs so first tip for capturing NFR is to actively start looking for them!
  38. 38. Using Stories for Non-Functional Requirements As a < user role > I want < goal > so that < business value > • Some teams like to use this template for everything that they work on including NFR because that's a consistent format. – Shaping NFR into user stories helps people outside the team understand the benefits better. • This can become a disadvantage, if these requirements may be seen by business stakeholders as optional or "nice to have". – It’s important to include the "so that" part to make it easy to see why such NFR stories are important from a business perspective to help ensure that they don’t get de-prioritized simply because they are not understood.
  39. 39. Using Stories for Non-Functional Requirements • Usually agile teams keep it simple and simply factor NFR into acceptance criteria for affected user stories. • This effectively makes work on NFR invisible. – The odd thing about doing this is that any stories which imply significant architecture work have higher estimates than others but because the architectural piece is below the surface it the estimate belongs to whichever story that gets worked on first. This can be difficult to explain to stakeholders.
  40. 40. Using Stories for Non-Functional Requirements • Another approach is to introduce "technical stories" to cover anything that needs to be built or restructured but is too difficult to explain to business people. • The developers are trusted to include only those technical stories that make sense often working within an allowance of such stories per iteration. • The benefit is that these don’t get de-prioritized by business people and yet these stories explicitly appear on the team board and progress on them gets discussed in daily stand-up meetings. • This approach is often popular for teams working on legacy systems with many complexities that need to be cleaned up and made testable. • One worry with this approach is that this excludes the business from deciding what the project budget is spent on. "Try to avoid tech stories. Look hard for a way to transform a tech story into a normal story with measurable business value. That way the product owner has a better chance to make correct tradeoffs." Henrik Kniberg’s
  41. 41. The beauty of User Stories for Non-Functional Requirements approach Is that all requirements (functional and non-functional): Look the same Can be understood by everyone Have the same visibility as other stories This approach is that normally elaborating requirements as user stories help a agile team understand user needs better.
  42. 42. Non-functional Requirements examples • Efficiency: Specifies how well the software utilizes resources (CPU cycles, disk space, memory) • Flexibility: Increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system. • Portability: Portability specifies the ease with which the software can be installed on all necessary platforms.
  43. 43. Non-functional Requirements examples • Security: Security requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software. • Performance: The performance constraints specify the timing characteristics of the software. • Usability: Ease-of-use requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users.
  44. 44. How do we gather user stories?
  45. 45. Trawling for Requirements
  46. 46. User Proxies
  47. 47. Customer Team
  48. 48. User Role Modeling
  49. 49. User Role Modeling Steps 1. 2. 3. 4. Brainstorm an initial set of user roles Organize the Initial Set Consolidate Roles Refine the Roles
  50. 50. Refine User Roles with Attributes
  51. 51. User Role Example
  52. 52. Where are the Details?
  53. 53. Details added as smaller User Stories
  54. 54. Details as conditions of Satisfaction/ Acceptance Criteria
  55. 55. Types of User Stories
  56. 56. The Backlog Iceberg
  57. 57. Breaking Down Epics
  58. 58. User stories vs. use cases User Stories Use Cases • Provide a small-scale and easy-touse presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish. • Must be accompanied by acceptance testing procedures (acceptance criteria) for clarification of behavior where stories appear ambiguous. • Describe a sequence of interactions, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”. May be delivered in a stand-alone document.
  59. 59. Software Requirements Specification IEEE 830 • The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. This document, known as IEEE Standard 830, was last revised in 1998. • The IEEE recommendations cover such topics as: – – – – how to organize the requirements specification document; the role of prototyping; the characteristics of good requirements; Recommended way to write functional requirements is “The system shall…” .
  60. 60. Software Requirements Specification IEEE 830 • IEEE 830–style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the users goals. – And lists of requirements don't give the reader the same overall understanding of a product that user stories do. • It's very difficult to read a list of requirements without automatically considering solutions in your head as you read.
  61. 61. SRS IEEE 830 examples: • The system shall allow a company to pay for a job posting with a credit card. • The system shall accept Visa, MasterCard, and American Express cards. • The system shall charge the credit card before the job posting is placed on the site. • The system shall give the user a unique confirmation number.
  62. 62. Software Requirements Specification IEEE 830 • Documenting a system's requirements to this level is tedious, error-prone, and very time-consuming. – Additionally, a requirements document written in this way is, quite frankly, boring to read. – Just because something is boring to read is not sufficient reason to abandon it as a technique; however, if you're dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it's not going to be read thoroughly by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.
  63. 63. Software Requirements Specification IEEE 830 • A powerful and important feedback loop occurs when users first see the software being built for them. When users see the software, they come up with new ideas and change their minds about old ideas. • When changes are requested to the software contemplated in a requirements specification, we've become accustomed to calling it a “change of scope.” – This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. • It doesn't matter how much effort is put into upfront thinking about requirements; we've learned that users will have different (and better) opinions once they see the software. – Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user.
  64. 64. Differences Between User Stories and SRS IEEE 830 The cost of each requirement is not made visible until all the requirements are written. • With stories, an estimate is associated with each story immediately. – The typical SRS IEEE 830 scenario is that one or more analysts spends a lot of time writing a lengthy requirements document. – This document is then handed to the programmers, who tell the analysts that the project will take longer as had hoped for. In this case, time was wasted writing the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time.
  65. 65. Tips for Writing Good Stories
  66. 66. Smelly user Stories
  67. 67. Literature • • • • • • • • • • • • Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5 powerpoint_ppt_presentation
  68. 68. Material For Further Reading • ry.htm • advantages-of-user-stories-for-requirements • n-functional-requirements-as-user-stories • • EEE830.pdf