User Stories and Epics

Question

As you know, epics consist of user stories. The user stories are short descriptions which specify the requests of the user. They can be perfect instance of the questions listed below:

Who, What, why

One of the customers told me that he wants a main page for anonymous users of that application, and this page must provide a method which takes that user to one of the movie lists listed below.

• New Releases
• Top Rated Movies
• Recommended Movies
• Genres

The main problem which I am encountered by is how I specify these movie lists in user story. I think a user story like that:

As an anonymous user, I want a main page so that I can easily access conventional movie lists.

How can I add names of these lists ? I have not faced any user story which specifies an example or detailed knowledge.

Answer 1

Before I say anything else, I want to say this - don't waste too much time trying to adhere to a best practice or a prescribed format. Instead, just do whatever lets you capture the requirements and move on. "Individuals and interactions over processes and tools", remember?

That said, a user story that specifies who/what/why is geared towards enterprisy projects, where you have users that have a specific role in the organization ("who"), and want a certain capability ("what") because they need get some work done ("why"). So, a user story is a high-level description, meant to facilitate understanding of why the business needs certain capabilities and how it all fits within the overall business processes and workflows. It's meant to be simple and to the point. It's not a formal requirement specification. Your example is, arguably, somewhat outside that framework, so you probably should adapt the formula to better suit your needs.

Now, clients will often specify requirements in a way that includes some design decisions ("there should be a page with links", instead of "we need a way to provide movie lists"), and if you're not careful about it, you'll put them in the requirements spec, and you'll be bound to those decisions without having evaluated them first. It's your job to consider different options, consult with the client, and make those decisions, not theirs. You may end up doing it in a different way, or you may decide to do it the way they originally described it.

So don't say that the user wants a main page; instead, say "As an anonymous user, I want to be able to access conventional movie lists, because [why - if applicable]", and associate a description with it, explaining what "conventional movie lists" means (or, if you are maintaining a glossary of domain terms, you can place the explanation there: conventional movie lists - New Releases, Top Rated, Recommended Movies, Genres).

Or you could do it in a more granular way, making a separate story for each list, if that makes sense, but again, you'll probably need to document somewhere that these are related, to put things in context.

Or you could just do
"As an anonymous user, I want to be able to access

New Releases,
Top Rated Movies,
Recommended Movies,
Genres,

because ...", and be done with it.

It probably doesn't really matter - depending on how important it is to understand the intricacies of the workflow of an anonymous user. I'm guessing it's not business-critical. You want to understand enough so that the user has a good experience with the software.

Answer 2

I would, first of all, entirely agree with Filip, and further suggest the following to be a deficiency of the ideal of "user stories."

• The only real-world person who can actually write such a "user story" is a computer programmer, not an actual user.

... because this "user (sic) story" is being expressed entirely in computer-software (implementation) terms, as though the user's "story" could actually bridge the technological gap between "a user, telling a story," and "what is necessary to cause a tiny silicon chip to perform a useful analog of what is described by that 'story,' in the context of a [vast] existing software application."

"User stories" can't actually do such a thing, because users are not programmers.

But, what they can very-usefully do is to simply be "real stories," which present the requirement to the team from the end-user's point of view – not(!) from the perspective of the growing application. Thus, instead of being mentally-filtered through an understanding of how the software application works, this being the most natural perspective of any software engineer, they speak for the user in the user's terms and voice. So, "the user's story" doesn't directly map into a software implementation plan, and perhaps that is precisely the point.