Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
How would you get from the first version to the second, if all you had at the beginning of the sprint was the first? What do you call the second version? Requirements? On it's face, the second version feels like a more complete, less ambiguous description, so if all this is about is what the definition of "user story" is ... –  Robert Harvey May 8 at 21:39
    
Is this what the user said they wanted or some sort of creation by a dev team member? –  JeffO May 9 at 3:27

3 Answers 3

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.

share|improve this answer
    
My guess is the OP's company is one that is making the transition to Agile and this effort is being led by a testing or QA group primarily. –  maple_shaft May 9 at 0:44
2  
@maple_shaft led? hahahaha! :) But yea, it's a transition process. So, I like this answer 'acceptance test'. It still seems a bit too detailed for being at the beginning of a sprint, though. Seems like this should be something that comes out during the sprint as the solution is created? –  DA01 May 9 at 1:47

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."

share|improve this answer
    
"modeling" = I like that. –  DA01 May 9 at 1:48

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]
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.