Why I don't use standard user story format that much

"If somebody is not interested in focusing on the end user and figuring out his real needs, no format on Earth can make him be interested."

I hear you... this is exactly why 75% of the backlog on my last project started with "As a product owner, I..."

I like the concept of user story format, and it's definitely a useful tool for thinking about what you're doing, but I think you can just as much mileage out of it by stopping and asking the appropriate questions, "Who?" and "Why?" whenever you get stumped trying to decompose requirements.

Thanks for speaking up!

Artem (and others of course!) --

Glad you agree, and I definitely hear ya (and am with ya) that sometimes the role itself can be dropped, in the cases where its obvious to all involved.

That said, I think having an appropriate actor specified is very often what allows us to cut a lot of details from what is included in the headline. Why? Because it adds context.

Let me give an example from a team I was working with a couple weeks ago.

Initially, they were writing stories that went something like this:
"User enters billing address so that credit card can be processed during checkout."

I say, "How bout this: instead of 'user' we can call this person our 'buyer' which implies their higher level activity (context) is 'checking out', right?"

Smiles all around and we end up with this:
"Buyer enters credit card billing address"

So, moral of the story (pun intended!): a well chosen actor is often the best tool that allows us to keep things simple without losing useful information.

Cheers!
MB

I've come to find the user/actor to be one of the most important parts of the story. We spend very little time on the user story sentence, and use mind mapping tools to capture the stories. I agree with Mike that they are very useful. It makes me wonder why so many posts here call it wasting time, I wonder if they are actually using the tool correctly.

>After meeting with our clients, we found that the user we had specified in our stories actually needed to be split up into different users, clerk and administrative types. This introduced a need in our software for a stopping point in the process so the data could be reviewed. This was something the users had assumed we knew but did not tell us. Specifying and asking about the user role exposed this need to us.

>Client's identify with the story more when we have an accurate user type listed. If we don't, sometimes they look past that story thinking it does not apply to them. We ask them first, who in their agency performs this action. Since we deal with whole agencies, we have many different actors performing tasks in our software.

>Consider the differences between these two sentences:
“As a job applicant, I want to update my profile…”
“As a hiring recruiter, I want to update my profile…”
These examples could end up in very different parts of the software system. Where an applicant may only be updating his resume or profile, the recruiter could be adding positions, updating company information, etc…, which could result in different fields being exposed, and different functionality when the profile is updated.

I can't say I've ever seen the need for a story that starts with "As an application developer/designer..." Can someone explain this? It sounds like they are creating too many user stories, getting too fine-grained with them, and including themselves as the user.