Should all requirements be written as User Stories?
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.
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.
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.
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.
Agree but it must not count towards your velocity, right?
Defects or technical debt, I meant.
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.
> 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/2011/01/06/in-scrum-should-i-assign-sto…
http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Bac…
^^ See the bullet under "considerations" that starts with "Resolving technical debt"
And one more link:
http://www.scrumcrazy.com/Handling+Non+Functional+Requirements+in+User+…
(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+Non+Functional+Requirements+in+User+…
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.