Overarching requirement vs user story
We have some overarching requirement such as security "all pages require login first" or formatting "all date format must be MM/dd/YYYY". How to write user story about it?
I plan to write a separate document that covers all overarching requirements, which is only referenced in only the first user story in all sprints references. Any following user stories don't reference it any more, and it's just implied.
If al pages require security, couldn't that be part of the definition of "Done"?
We have some overarching requirement such as security "all pages require login first" or formatting "all date format must be MM/dd/YYYY". How to write user story about it?
I plan to write a separate document that covers all overarching requirements, which is only referenced in only the first user story in all sprints references. Any following user stories don't reference it any more, and it's just implied.
Would it be reasonable for the Product Owner to deprioritize that story, so that one or more Sprints are completed in which the requirement is not satisfied?
Chris and Jennifer, I think it is a great idea to make it part of definition of Done. Thanks!
Ian, how to handle this situation:
sprint 1,
user story A: As a user of [Neo's product], I want to register myself so I can login
user story B: As a user of [Neo's product], I want to order a [Neo's product]
user story C: As a user of [Neo's product] I want to see all dates formatted " MM/dd/YYYY"
sprint 2:
user story D: As a user of [Neo's product], I want to track my orders
Do you think it would be reasonable, in the situation you describe, for the Product Owner to deprioritize stories A (registration) and C (date formatting) to Sprint 2?
Would Sprint 1 then result in an increment which is still valuable and from which useful feedback might be obtained?
Look at the Scrum Guide section on Definition of Done. These sound like organizational level DoD elements. So that is where I'd put them. Then each team can have more stringent DoD that supplement the organizational DoD.
I believe your idea of a story could lead to problems. It would never be finished but would have to be included in every sprint. There is a possibility that the PO could see delivery of new functionality more important to the business than following those rules. If it is a story, that is entirely possible. But make it part of DoD at the organizational level, then it has to apply to everything all teams call "Done".
@Jennifer
The form of a user story is fine for overarching requirements (and non-functional ones, and, well, pretty much everything really
I would like to kindly disagree with you on this. You gain nothing from writing your nonfunctional requirements in the form "As a database, I want to be fast". A user story is the most useful when it's a summary of an an actual conversation you've had with a human being. The post card analogy from Jeff Pattons book is a great way of illustrating this point. If you start fabricating user stories, or just squeeze everything into the As a-I want-So that format, you devaluate the actuall user stories you might have, and the power they contain in terms of providing context and guidance, kinda in the same way that a good sprint goal provides guidance.