How Do You Know A User Story Will Do What You Expect?

This is a question many Product Owners ask.? So, let’s take a minute to talk about the purpose of User Stories.??

In simple terms – a Use Story provides a developer with the “ask.”? What do you want?? Why do you want it?? How do you know what you asked for was provided???

The scope of a User Story should be large enough to do the work in one sprint. The length of the sprint will determine the “max.” If one User Story is too big, decompose it and link the stories together!?

A well-written User Story doesn’t mention the “how” – that is the developer's responsibility.??

That all seems so simple, right? It is if the work to be done can be defined uniquely without dependencies on other work. That’s when it gets a little cloudy. How do you reference other work done????

So many questions – so let’s get to some answers:?

1. Be sure to title the User Story with a value that describes what you are asking – “Provide ability to see customer info when processing claims”?
2. The “what” and “why” should reference ONLY the work to be done in the User Story.? “As a claims processor, I need to be able to see my customers' profiles on the claims review screen while processing their claims so that I have all I need to complete the process in one view.” Note that there is no “how” in this statement. Just the “what” and “why.”?
3. If there are other User Stories that have information that is relevant – add the links as Additional Information – this is ONLY for reference and should not be included when developing Acceptance Criteria.?
4. How do you know “you got what you asked for”?? The answer – Clear and Complete Acceptance Criteria.? You know what you want and how you expect it to work, so tell the Developers, QA Analysts, and Customers.? ONLY include criteria for the actual work being done – there should be no criteria to validate work done in any other User story (even if they are linked as additional information).??
5. Last of all, if there are other artifacts (User Stories, Features, etc.) that are “related” to the User Story, LINK THEM! There are many types of links, such as “relates to,” “is dependent upon,” and “is blocked by.” By providing these links, you will have full visibility of the work, your Scrum Master will love you, and team grooming will be a “non-event.”?

As a team, your developers, Scrum Master, and QA Analysts will appreciate the quality of a User Story.? As a Product Owner, you will find yourself getting into a groove and the components become second nature!??