User Stories – Large Misconceptions. Part 1.
One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.
Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.
User Stories are Organic!
If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.
Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.
As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.
The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.
While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.
User Stories are not a Catch-All Artifact!
The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.
In this case, they’re suggesting supplementing the Story with a known additional artifact form.
This is great!
Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.
The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.
One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.
As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases
Next post, well finish with the other two misconceptions
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 protected].