Beware of user stories where “so that” is a technical capability, not any value to the end user. This is very similar to no business value, but the value listed is technical.
Example: As a tester, I want to have detailed test plans so that when the system is completed, I can test the system.
Problem: This story refers to a specific user and has a technical benefit: the existence of test plans. Users want quality software, but they don’t care about test plans
Improvement: The improvement would be to delete this story. Part of the team’s test plan should be found in the acceptance criteria for each story.
Recognizing the common failure patterns in these written stories will help you avoid these problems and keep your conversations from losing their focus, leading to a more flexible development effort. Writing better stories will influence the conversations that happen, so it’s well worth the time up front to understand the value and format of a good story.