As I hear more and more BAs talking about user stories I feel the need to begin a dialogue on our blog. User stories have been promoted by the iterative and agile software development approaches as a quick way to elicit and document user requirements. Some BAs are being told that user stories are the only requirements that they need. I disagree. Alister Cockburn appropriately writes that user stories “are markers that promise a conversation about what is associated with the phrase on the card.” Cockburn also notes that these are not the only tool used to gather requirements on an agile project and in fact this technique may be a very weak strategy for many types of agile projects (e.g. projects with very large or diverse stakeholders).
User stories are brief descriptions or phrases written on an index card called a story card. They can be a great starting point for analysis because they are easy for users to describe and easy to document. They give an analyst or developer who is new to the business area examples of the type of work that is accomplished by the business. They also can be used to develop initial high level test cases.
The limitations of user stories are easily seen from the strengths above. They are not detailed and only describe a specific business transaction or situation. The number and choice of stories determines how well they, as a group, cover the scope of the business area. They do not formally call out data needs, business rules, or include consistent definitions.
For projects where user stories are dictated as the preferred requirements deliverable the experienced BA will be able to use them to drive down to detailed business and functional requirements which will complete the picture.
Tell us what you think!
5 Comments
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.
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.
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
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.
Angie
Good pick up about test/acceptance criteria.
Here’s a good short blog post on an easy to adopt format.
Given
When
Then