Let me digress to make a comparison (in the process I may age myself but so be it) – I think back to the time when desktop publishing was first introduced. With desktop publishing draft copies gained a way of looking complete, finalized and picked up an air of authority based solely on the crisp appearance of the material.
I think of user stories in the same way.
I don’t like to review user stories and believe that they are always “right.” I don’t believe that the stories are always “complete.” And I don’t believe user stories can be the authoritative source for anything more than “what the author thought the application would do at the time they wrote the story.” I am a committed skeptic.
Like reading the answer key while taking a quiz, I don’t like to read user stories before I’ve gathered my own ideas. I worry that the user stories will stifle my testing thoughts.
So what do I really do with user stories? I put them aside at first and …
I think about what functionality is either being introduced or enhanced in the coming build and what test ideas I have collected in my notes already.
I think about existing functionality and what might need to be regression tested.
I review the data model. I expect myself to be able to envision how the application is being changed by reviewing the database changes. I usually can. I pick up more test ideas this way.
Then I pick up the user stories and …
I scan stories for their titles, if the title is written well, I get the point. I don’t continue to read for the details until after I’ve thought about the functionality being introduced or improved. So I’ll take the title of a user story and then think through ways to challenge the premise of the story.
I go back and read the user stories thoroughly. I ask questions. The questions I ask often result in early bug finds and more user stories being written. If I can find issues that early in the process, that’s great.
I write notes while I read the stories. My notes are often more test ideas.
In my experiences with user stories, the most helpful aspect is whenever I learn about a scenario that I didn’t think about – some nuance that I didn’t foresee. I bump these test ideas up early in the process because these are the stories that I feel I can learn from – the stuff I might not have expected.
Despite sounding somewhat negative or skeptical towards user stories, I actually do like them. I generally prefer user stories to more formally written requirements.
User stories are especially more helpful than the requirements that often get written around the medical software I’ve worked with that has so many requirements commanding: “the system shall X” but yet much of the nuance of “how” is not addressed.
I also like to think about and test for the “what if the system doesn’t.” Testing around error conditions and seeing how graceful a system handles certain states or conditions is important. I don’t see user stories written around these concepts though, instead the user stories I’ve worked with have been pretty happy path focused. And I am a rainy day person.
My largest frustration with user stories is if I follow the detailed path that has been drawn out and I find a bug just following the story – a large functional bug. I’m disappointed to realize that unit testing didn’t pick up on the issue. If I think of a variance or nuance from the story, I don’t necessarily expect those issues to have been found or thought about – but I do expect the happy path basic operations to be functional. Just because I expect this and wish for this to be true, doesn’t mean that is what I’ve experienced.
Overall, I think user stories are more digestible than requirements but I can appreciate that some features of an application aren’t described as well in the story format as well as other features. This is why I think having too prescriptive of a story format is a detriment that can be avoided. While, I would not vary the format of each user story because that might result in making the collection of stories hard to follow, I would not use the same format just to be consistent. Some features might be better told in longer prose and some features might be better explained with a grid or a table. I think any format used whether a user story or a requirement stands the chance for not being the best format for the requirement being described. I suppose user stories are like any tool or hammer we learn, there may be a temptation to overuse the format, seeing everything as a nail as the saying goes.
On a recent project where I was working with user stories, I would like to have more involvement earlier on with reviewing and participating in writing the stories. I’m surprised I didn’t/haven’t had that opportunity. I’d like that opportunity – any time I can gain experience from a different perspective (like gaining the experience of producing the stories versus being a consumer of the stories) I learn a great deal.