1

I've user story section in my project requirement document. User story goes like this,

As a user I want to check in to the venue

and another one,

As a user if I already checked in then check in button should be hidden

I am going in the right direction with this or I should rethink this stories?

  • 1
    Adding some context with "so that..." would probably provide implementation guidance to your stories. – Todd A. Jacobs Oct 9 '13 at 6:42
  • 1
    "project requirement document"?? Surely you mean product backlog? – Dave Hillier Oct 9 '13 at 8:50
4

Are you writing Acceptance Criteria along with you User Stories, if not then it might be a good time for you to start writing them. From the example you gave, I believe that

then check in button should be hidden

becomes one of the acceptance test of the first story:

As a user I want to check in to the venue [so that ....]

Each acceptance test represents some expected result from the system. A story will not be considered complete / done unless it fulfills all of the acceptance criteria of that story.

Some useful links to explore more about acceptance tests:

| improve this answer | |
1

In addition to the answer that Aziz gave, I would ask whether your project truly has a single kind of user or if there are aspects that differentiate your users. If you do have more than one type of user, it is important to identify which one you are writing the story for (even if it feels like it should be obvious). In other words, instead of saying "as a user", you might say "as an anonymous user" or "as a registered user". We often take this a step further and develop pragmatic personas for use in our stories.

| improve this answer | |
1

User Stories should follow this format.

As a (role) - This can be an end user or a business proxy

I want - A description of what needs to be done

So that - the definition of the value

Acceptance criteria is then required so you know when you are done. This can be a bullets list, like you have, or context specification style (part of BDD - Business Driven Development).

The one major bit of advise I have is do not write the User Stories on your own. Creating a backlog using User Stories is a collaborative technique. Without this, you will be missing the point and main advantage of this approach. Emergent requirements and valuing customer collaboration over contract negotiation.

If you would like to know more I suggest reading Mike Cohn's User Stories Applied.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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