Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Should all requirements be written as User Stories?
Last Post 06 Mar 2013 08:47 PM by Susanta Kar. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Veteran Member
Veteran Member
Posts:1676
Ian Mitchell

--
21 Feb 2013 06: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
    Basic Member
    Basic Member
    Posts:156
    Sanjay Saini

    --
    21 Feb 2013 06: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
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    21 Feb 2013 08:55 PM
    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

    --
    21 Feb 2013 10:00 PM
    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 Stopa
    New Member
    New Member
    Posts:2
    Michael Stopa

    --
    21 Feb 2013 11:04 PM
    Agree but it must not count towards your velocity, right?
    Michael Stopa
    New Member
    New Member
    Posts:2
    Michael Stopa

    --
    21 Feb 2013 11:07 PM
    Defects or technical debt, I meant.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1676
    Ian Mitchell

    --
    21 Feb 2013 11:21 PM
    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:411
    Charles Bradley

    --
    23 Feb 2013 06: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:411
    Charles Bradley

    --
    23 Feb 2013 06:05 PM
    Charles Bradley
    Basic Member
    Basic Member
    Posts:411
    Charles Bradley

    --
    23 Feb 2013 06: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 Kar
    New Member
    New Member
    Posts:20
    Susanta Kar

    --
    06 Mar 2013 08:47 PM
    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