Scribd Logo
Upload

Welcome to Scribd!

  • 319 views

    Writting Good User Stories

    Uploaded by

    cjpol34
    User stories are a concise way to capture requirements using a who, what, why format. They combine written descriptions with verbal conversations to clarify details just before development. A user story includes a card with a description, conversation section, and confirmation of tests. Following INVEST principles ensures user stories are independent, negotiable, valuable, estimatable, small, and testable.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd

    Writting Good User Stories

    Uploaded by

    cjpol34
    319 views14 pages
    User stories are a concise way to capture requirements using a who, what, why format. They combine written descriptions with verbal conversations to clarify details just before development. A user story includes a card with a description, conversation section, and confirmation of tests. Following INVEST principles ensures user stories are independent, negotiable, valuable, estimatable, small, and testable.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    User stories are a concise way to capture requirements using a who, what, why format. They combine written descriptions with verbal conversations to clarify details just before development. A user story includes a card with a description, conversation section, and confirmation of tests. Following INVEST principles ensures user stories are independent, negotiable, valuable, estimatable, small, and testable.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    319 views14 pages

    Writting Good User Stories

    Uploaded by

    cjpol34
    User stories are a concise way to capture requirements using a who, what, why format. They combine written descriptions with verbal conversations to clarify details just before development. A user story includes a card with a description, conversation section, and confirmation of tests. Following INVEST principles ensures user stories are independent, negotiable, valuable, estimatable, small, and testable.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 14
    At a glance
    Powered by AI
    The key takeaways are that user stories seek to combine written and verbal communication for requirements, with details added through collaboration just before development. User stories should be independent, negotiable, valuable, estimatable, small, and testable.

    The three parts of a user story card are: 1) Card - A written description of the user story, 2) Conversation - A section for capturing further details, 3) Confirmation - A section conveying what tests will confirm completion.

    The three components of a user story description are: 1) User role, 2) Goal, 3) Reason.

    Introducing User Stories

    Agile Requirements

    Key Principles for Agile Requirements


    Active user involvement is imperative Agile teams must be empowered to make decisions Requirements emerge and evolve as software is developed Agile requirements are barely sufficient Requirements are developed in small, bite-sized pieces Enoughs enough apply the 80/20 rule Cooperation, collaboration and communication between all team members is essential

    Requirements are a Communication Problem


    Written requirements
    can be well thought through, reviewed and edited provide a permanent record are more easily shared with groups of people time consuming to produce may be less relevant or superseded over time can be easily misinterpreted instantaneous feedback and clarification information-packed exchange easier to clarify and gain common understanding more easily adapted to any new information known at the time can spark ideas about problems and opportunities

    Verbal requirements

    A picture is worth a thousand words

    User Stories
    seek to combine the strengths of written and verbal communication, where possible supported by a picture.

    What is a User Story?

    A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.

    User Story Cards have 3 parts


    1. Card - A written description of the user story for planning purposes and as a reminder Conversation - A section for capturing further information about the user story and details of any conversations Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected

    2.

    3.

    User Story Description


    As a [user role] I want to [goal] so I can [reason]
    For example: As a registered user I want to log in so I can access subscriber-only content

    User Story Description


    Who (user role) What (goal) Why (reason)
    gives clarity as to why a feature is useful can influence how a feature should function can give you ideas for other useful features that support the user's goals

    User Story Example: Front of Card

    User Story Example: Back of Card

    How detailed should a User Story be?

    Detailed enough for the team to start work from, and further details to be established and clarified at the time of development.

    INVEST in Good User Stories


    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 features, not tasks. Estimatable 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 Stories Summary


    User Stories combine written and verbal communications, supported with a picture where possible. User Stories should describe features that are of value to the user, written in a users language. User Stories detail just enough information and no more. Details are deferred and captured through collaboration just in time for development. Test cases should be written before development, when the User Story is written. User Stories should be Independent, Negotiable, Valuable, Estimatable, Small and Testable.

    You might also like