Anyone on the Team Can (and Should) Create and Update User Stories!
I've seen the position of "only the product wner can write stories" taken time after time when I'm coaching agile teams. I'll enter a Sprint Planning session and we'll look at the Product Backlog. The team will complain about the backlog not being detailed enough or containing the 'right' set of stories. We'll spend literally hours reviewing them and debating their intent until we run out of time in our time-box and need to reschedule the planning session.
Inevitably these teams point to the Product Owner as being the problem-complaining that they were not prepared.
As an agile coach I always challenge the entire team in these situations. It's every team member's responsibility and privilege to write and refine the stories on their product backlog. You see, user stories don't simply capture 'requirements'. Instead, they capture all work (let me repeat that) all work that will be undertaken by the team in order to meet the business's expectations for the project.
Given this, it's no wonder the product owner (or BA) can't fill in a complete set of stories. Nor do they have the functional expertise that the team has in areas of software analysis and design, or development, or testing, or converging a product for customer use.
The user stories must be truly owned by the entire agile team. Sure, the product owner will probably spend significant time writing, refining, and ordering them. But consider that to be simply a "seeding pattern". The stories aren't truly complete until the team has iteratively refined them together. In Scrum and oft used term for this is - Grooming the Backlog. This is where the team gathers, either as a group or individually, and refines the stories encompassing the backlog.
Underestimating the Power of Acceptance Tests
Much of the focus of writing user stories is on the story-side or behavior-side of the card. Often there is little to no investment in developing acceptance tests (Confirmations) that are placed on the back of the card.
Why is that? My view is that defining test cases is hard for most teams to grasp. It's sort of an afterthought and not everyone gets the intent or power of acceptance tests. I consider them more important than the user story description, and here are some helpful ways to view them:
- Consider them mini-UAT tests at a story or feature level
- They confirm Sprint Done-Ness from the perspective of the customer and the tester
- They enable testers and BAs on the team to quantify key conditions that the software must meet
- They drive the design and capability of the software; consider them defining the business logic for a story
- They are a collaboration driver between developer(s), tester(s), BA(s), and product owner
- They are either working or not; there is no in-between
There's quite a bit of debate surrounding how many acceptance tests should be defined for each story. Certainly, they are not intended to exhaustively test the story-so they are not a complete list of test cases. I usually recommend somewhere between three and seven acceptance tests per story as determined by the team. One or two is certainly too few, and 25 clearly too many.
There is also debate surrounding how to phrase the acceptance tests. I've seen the following patterns for them across teams' I've been coaching:
- Verify that..."some behavior"
- Confirm that..."again some behavior"
- If I do this...this results
- Under these preconditions, confirm that..."some behavior"
What's important here, truly important, is not the phrasing, but that you define and confirm acceptance tests on a story by story basis. It drives quality collaboration and quality results within your agile teams.
Wrapping up - I hope I've clarified these four misconceptions and ultimately improved your user story writing.
Don't forget to leave your comments below
Robert 'Bob' Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at email@example.com.