Comments on: User Stories

By: Craig

Craig — Fri, 08 May 2009 12:33:14 +0000

Angie

Good pick up about test/acceptance criteria.

Here’s a good short blog post on an easy to adopt format.

Given

When

Then

By: Angie

Angie — Tue, 05 May 2009 21:02:21 +0000

Thanks Craig. The format you describe for writing user stories is the same one I found in Mike Cohn’s book, “User Stories Applied for Agile Software Development”, Pearson Education, 2004. I recommend the Cohn book as a great reference for those who are new to agile projects and have not worked with user stories before.

I definitely agree with Barb and everyone else who discussed that user stories are great tools for prioritizing features/functionality, organizing work, and estimating effort but are considered as incomplete requirements in agile projects. Test cases are typically still written to confirm the acceptance criteria and error conditions.

BAs or Developers can use other techniques in addition to conversation to flesh out the requirements, such as activity diagrams to document complex logic, or screen mockups to verify user tasks, data or business rules needed. Instead of writing documents – usually whiteboards are used to sketch out what is not well understood. Agile purists often quote that working software is the only deliverable used to confirm requirements rather than voluminous documentation.

In summary, I think user stories can be thought of as vertical slices of functionality that users need to complete a business goal, can be implemented quickly (usually within 1 week- 30 days), use minimal documentation, act as reminders for further conversation, are written in business language and primarily used to agree, prioritize, and estimate the effort to implement those features for each iteration (i.e. sprint or release). And they are not requirements deliverables in of as themselves because they are incomplete.

By: Craig

Craig — Thu, 16 Apr 2009 12:51:35 +0000

Barbara

I thought I wuld add some more to your definition.

A user story may used as you describe as a conversation marker, but is often more than that.

For example, it may e accompanied by detailed acceptance criteria.

A user story can also come as a headline to a multi-page document if that’s what you need to fuly flesh out the idea.

Naturally it can live in an electronic format and doesn’t have to be a card, although I am a huge fan of the physical task board.

Another key feature is that it should be scalable to the sze of a project’s sprint.

Also mising is one of the more popular models for structuring stories;

“As a.. I want to… so that…”

By the way, I’ll be talking about this in the Sydney and Melbourne BA World symosiums.

Cheers

By: Helen Chesterman

Helen Chesterman — Wed, 15 Apr 2009 21:09:19 +0000

It’s really great to hear people talking sense about User Stories. For a while now I have felt like I must be missing something when I hear that in agile development the User Stories “are the requirements”. I always think to myself no, they are a way of organising and prioritising tasks, a very good way I have to say but never the less that to me is the purpose user stories serve on an agile project.
While I whole heartedly agree with the principle that there is no point in producing pages and pages of requirements documentation that no one will ever read there this is not the same as saying we should produce none. It is important to remember the other agile principle that things should be made as simple as possible BUT NO SIMPLER.

By: Kevin Brennan

Kevin Brennan — Wed, 15 Apr 2009 12:23:00 +0000

My sense is that user stories serve much the same function as a feature list in more traditional approaches–that is, that they’re a high-level summary of something the application is supposed to do. The main point is to serve as a basis for estimation of work and agreement of what’s going to be delivered.

Once a user story is selected for implementation, the product owner (BA or whatever) will work with the developers to flesh out exactly how the story is implemented in a specific iteration. These more detailed requirements get captured in conversations, on whiteboards, etc.