Forums

By posting to our forums you are agreeing to the Forum terms of use.
Should all requirements be written as User Stories?
Last Post 07 Mar 2013 12:47 AM by Susanta. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Advanced Member
Advanced Member
Posts:559
Ian Mitchell

--
21 Feb 2013 10:22 AM
    I often get asked by clients whether or not *all* of their requirements should be written as User Stories. These include business requirements, technical requirements, defects, and NFR's (Non Functional Requirements).

    Here is the advice that I give:

    - Business requirements: Yes.
    - Technical requirements: Rarely, these are usually tasks needed to complete a User Story.
    - Defects: No. They should be raised *against* a User Story. Note that the absence of a suitable User Story implies technical debt (including absent or inadequate tests).
    - NFR's: Yes, unless they are so pervasive that they should be included in a Definition of Done.

    Does anyone else have a take on this? I suspect Mike Cohn would argue that pretty much all of the above should be User Storyfied.

    NB I also advise that a User Story is incomplete without Acceptance Criteria. It is permissible for User Stories to be added to a Product Backlog without them, but Acceptance Criteria *must* be specified before a PBI can be admitted by a team to their Sprint Backlog.
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    21 Feb 2013 10:30 PM

    Anything which comes from the business or end user should be recorded as a user story. A defect can be converted into a user story based upon the team's grooming. There are chances that a bug is reported from production now for a user story which was released five sprints back.
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    22 Feb 2013 12:55 AM
    No. Scrum is very neutral on how you write Product Backlog item. Infact, Scrum never mention anything about User Story. Use any format that makes sense and makes everyone productive.
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    22 Feb 2013 02:00 AM
    A team should do just enough to understand the need such that they can feel comfortable forecasting and accepting the work into a sprint. How it's written is irrelevant. The User Story format is often useful early in a maturing team since it codifies value and context, but it's just one of many potential options a team might try.
    Michael
    New Member
    New Member
    Posts:2
    Michael

    --
    22 Feb 2013 03:04 AM
    Agree but it must not count towards your velocity, right?
    Michael
    New Member
    New Member
    Posts:2
    Michael

    --
    22 Feb 2013 03:07 AM
    Defects or technical debt, I meant.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    22 Feb 2013 03:21 AM
    HI Michael

    In my opinion, if the defect or techdebt is being raised for work that is in-sprint then it will not count towards velocity. It's just another task that has emerged.

    If a defect or techdebt s being raised for work that has been accepted, then my default position is that it *should* count towards velocity, and needs to be planned in to a sprint like everything else.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    23 Feb 2013 10:04 PM
    > Should all requirements be written as User Stories?

    Sure, if that is what the team is comfortable with. Like Joshua said, Scrum does not prescribe here. User Stories are one of many Scrum Technique Patterns for representing Product Backlog Items.

    In terms of whether to assign story points/velocity to defects and technical debt -- Scrum is also largely silent on that topic. There is no one best way to handle that, and the optimum way depends quite a large amount on team and organizational context.

    Here are some of my thoughts on that topic:
    http://www.scrumcrazy.com/bugs
    http://scrumcrazy.wordpress.com/201...s-to-bugs/
    http://www.scrumcrazy.com/Scrum+Str...nt+Backlog
    ^^ See the bullet under "considerations" that starts with "Resolving technical debt"

    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    23 Feb 2013 10:05 PM
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    23 Feb 2013 10:07 PM
    (Sorry, I keep forgetting that the forum squishes the links so you can't see the titles. (You can if you hover over them) It's also impossible to edit a post given the current forum configuration.

    Anyway, this last one:
    "Handling Non Functional Requirements in User Stories"
    http://www.scrumcrazy.com/Handling+...er+Stories


    Susanta
    New Member
    New Member
    Posts:20
    Susanta

    --
    07 Mar 2013 12:47 AM
    I believe based on the nature/type of the engagement, technical stories may be there or not. Say for any reengineering project - technical stories cold be potential candidates but for general product development/project user stories should mean literally user stories. Technical know-how should come as task if not there is some technical requirement is attached to(rare).

    Defect/Bug - sometimes could be reversed one purely PO's call to take it or throw it.

    NFRs should be part of user stories. Sometime, these are more like hidden expectation towards the end of the project generally we come to know.
    You are not authorized to post a reply.


    Feedback