I’m with an org that is trying to transition to Agile. One thing that I’ve been struggling with is what they call user stories. In my experience, a user story would be this:
Use should be able to accomplish task x using tool y
During the sprint, we’d then design a solution to enable this.
However, this is what we’re writing:
User should click on button A to go to page B to read text C where they will then select option D which will then redirect them to page E. Data F will be saved to the database.
To me, this reads as a solution, which is what the sprint is for.
Are the scenarios where the latter is actually a proper user story? Or, if not, is there a proper term for that type of detailed “solution description” within an Agile process?
2
The second example you gave is certainly not a traditional User Story, which is generally formulated something like As a *role*, I want *goal/desire* so that *benefit*, but is what I would call ‘acceptance criteria’.
According to the Wikipedia article linked above:
Every user story must at some point have one or more acceptance tests
attached, allowing the developer to test when the user story is done
and also allowing the customer to validate it. Without a precise
formulation of the requirements, prolonged nonconstructive arguments
may arise when the product is to be delivered.
Your “User should click on button A …” scenario looks an awful lot like such an acceptance test.
2
Have a look at the Wikipedia article for User Story Modeling.
Notice that, while subsequent steps involve things like GUI mockups and Story Boards, the very first step is gathering user stories, and they are quite specific:
Scenario Go-Dutch barbecue
Start: This Sunday Peter, Putri, and Peng meet at the park for a go-Dutch barbecue. They use the Group Account app to do the
accounting.Step 1: Peter brings the meat for $12. Peter adds this item to the Group Account app.
Step 2: Putri brings salad for $9. Peter adds this item, too. The app shows that by now the average share is $7 and that Peng still have
to bring these $7 while Peter gets $5 out and Putri gets $2 out.Step 3: …
Your second example probably falls under the subcategory GUI Mockups. But it’s still considered “User Story Modeling.”
1
neither of those are user stories, though the first one is closer than the second
a user story should express what the user wants to do and why, but not how.
as a [user], i want to [do something], so that [benefit]
a user story is a functional requirement, not a design specification
if what the user wants to do is complex, by all means draw screen mockups and navigation diagrams – but don’t bother dressing up the design in story clothes; they don’t fit, and they’re not necessary
note: to really flesh out the requirements, use test scenarios, e.g.
given [preconditions]
when [triggering event/condition]
then [expected outcome]