In agile dev, how do you organize user stories? [closed]

Question

How do you go about organizing user stories?

What I did was this for a web application:

Made a title for a web page like 'index', then listed all the stores the user can do on this page.

I continued on for all the pages.

Is this the most effective way?

Coral

Answer 1

I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:

As a [role] I need [capability] so that [desired outcome].

A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:

Concern: Some Activity
Context: When doing such and such
Observation: This thing should be added to the database
Observation: The thing should get a new unique ID
Observation: The thing should be related to that thing

Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)

It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):

Concern: Finding Stores
Context: When looking for a product with the best price
Observation: The web page should display a grid of store thumbnails that contain the users search product
Observation: The stores should be sorted such that those with the lowest price appear near the top of the page
Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for

The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.

Concern: Retrieving Stores
Context: When searching for Store entities containing a specific Product
Observation: A collection of StoreResultDetail should be returned
Observation: The collection of stores may be empty
Observation: Each StoreResultDetail should contain the store name
Observation: Each StoreResultDetail should contain the price of the Product
Observation: Each StoreResultDetail should contain the URL of the store's web site
Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site

The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.

Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.

Floristic

I like this a lot. So then Observation gets as technical as it can get? Would it contain things like "the user should be able to tab to the next textbox."? – Seismic

Answer 2

Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.

Roundabout

Answer 3

In our shop, we write up Use Cases. Examples of Use Cases:

Create New Customer Account
Assign User Rights
Receive Order
Accept Payment

We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).

From the use cases, we then begin to sketch up web pages.

You can also make Use Case diagrams:

Durance

Answer 4

I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.

I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.

Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.

Gorgoneion

Answer 5

We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.

Holland