From the mailbag:
I enjoyed the course and found the information practical and useful. I had meant to mention something that occurred to me regarding User Stories.
User Stories seem to serve the same purpose as the user goal statements of use case analysis as implemented by Alistair Cockburn. As I’m sure you know this approach captures requirements at a high (sky), implementation (sea level) and sub process (sea floor).
While the textual story approach works well when forming requirements with non technical domain experts, it is not always obvious (to me) that everything has been captured.
Perhaps one approach would be to transcribe the User Story into a User Goal Statement template with the following ‘mapping’:
User Goal (present tense verb noun clause) = User Story Title
Primary Actor = User Story Narrator
Goal Purpose = User Story Business Value
Success Scenario/Minimum Success Guarantee/Other Stakeholder Requirements = User Story Acceptance Criteria
Transcribing the User Story into a Use Case Goal Statement template may seem unnecessary, but there are some possible benefits:
Ensure that User Story text contains all required elements within a consistent template. Cross story elements (User roles, stakeholders etc.) become more apparent.
There are also well established tools and techniques for Use Case review, consolidation and requirements management, including effort estimation, dependencies, complete/correct checks etc.
When useful, some level of use case step breakdown for happy and alternative paths could prove useful for ensuring that all required tasks are captures, and for exception condition analysis requirements.
Just a thought.
Thanks for the kind words and the thoughtful observations here. I especially enjoyed the third day working with your company after the course — I could see a lot of lights come on as people were able to master concepts and work out how to apply them in your environment.
I’ve worked with RUP-style use cases, Cockburn-style use cases, and user stories. I personally preferred user stories for the kind of work we were doing. But that’s not a Scrum thing, just a personal preference for moving more of the detailed analysis out of planning into Sprint execution.
In other environments use cases may be a better fit, and you’ve listed some persuasive reasons. Scrum is agnostic on this point.
I have noticed a tendency to leave Product Backlog Items too big before committing into Sprints. This will happen with user stories or use cases. To split use cases in to thin vertical (demonstrable, testable, business value) slices, consider splitting the alternate flows into separate PBIs. You may still wind up doing some of them in the same Sprint though.
Download the PDF version: Scrum with Cockburn style Use Cases_blog