When working in Agile, what's best practices for a user story?

Discussion in 'Agile and Scrum' started by Jason Sparks, Feb 4, 2015.

  1. Jason Sparks

    Jason Sparks Member

    Joined:
    Nov 27, 2014
    Messages:
    4
    Likes Received:
    0
    Can you give me best practices guidelines for writing a user story when working in Agile? I want to know how long or detailed a user story should be.
     
    #1
  2. Vinutha

    Vinutha Manager
    Staff Member

    Joined:
    Jan 30, 2015
    Messages:
    275
    Likes Received:
    79
    We are checking on this with our Trainer, will update once we receive a response.
     
    #2
  3. Vinutha

    Vinutha Manager
    Staff Member

    Joined:
    Jan 30, 2015
    Messages:
    275
    Likes Received:
    79
    Here is the response:



    User stories don't have any details! It's just a card - a reminder that we need to implement some feature. Details should come out in conversation with customer (or PO). Remember - individuals and interactions are more important, customer collaboration is more important in agile (refer agile manifesto)

    The general guidelines for writing good user stories are as follows -
    1) Write stories with varying levels of details - i.e. small (doable or INVEST) stories for immediate sprint and large epics for stories in later sprints, vague stories for sprints far away
    2) Start with goal stories - e.g. As a user I want to search (which is vague)
    3) Then break it into smaller stories as needed to bring clarity (e.g. As a user I want to search by location, as a user I want to search by multiple criteria, as a user I want to see search results on one page, etc.
    4) Write stories for 1 user type, at a time
    5) Keep UI out of scope of stories, let it come out in conversation
    6) story for immediate sprint must be small and meet INVEST criteria
    7) PB should always be DEEP
    8) Use 3C's - card (which is story), conversation - which is when you know more about story - by talking to PO and confirmation - acceptance criteria for each story, which should be clear at end of conversation with PO
    9) Whatever the team learns from conversation can be recorded for future reference - how much detailed it should be? - depends on your project's context :)
     
    #3
    MukeshShende likes this.
  4. Om Prakash Bang

    Om Prakash Bang Well-Known Member
    Alumni

    Joined:
    Feb 18, 2015
    Messages:
    92
    Likes Received:
    39
    The general guidelines for writing good user stories mention are all good. User stories are granular or lowest level which are taken up into sprint planning meeting. When a requirement is at epic or feature level, it is good to create business process flow diagram, context diagram, use case diagram, business rules, data dictionary etc. These models can be progressively elaborated through out product development life cycle. We can always give a reference of these artifacts in user story.

    Following techniques can be used to decompose, feature / bigger user stories into smaller user stories, which can fit into sprint.
    1. Data flow - Main, alternate and exceptional flow
    2. CRUD operation
    3. User Role
    4. Business Rule
    5. Data subset
    6. Operating system
    7. Device compatibility
    8. functional and nonfunctional
    9. Security, logging, error handling etc.
    Most important part of user story is acceptance criteria. If the acceptance criteria is not articulated properly, then you never know whether user story is completed or not. It will result into conflict. Every line of acceptance criteria should translate into binary, true / false, yes / no.
     
    #4
    madhukar2sri and Shruti like this.

Share This Page