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
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.
Data flow - Main, alternate and exceptional flow
functional and nonfunctional
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.
The Simplilearn community is a friendly, accessible place for professionals of all ages and backgrounds to engage in healthy, constructive debate and informative discussions. Get your pressing questions answered,
participate in monthly contests, create polls to get a feel for the market, build your network, and more! Pull up a chair and come join the discussion -today!