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!
8 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
I’m new to User Stories (currently reading Agile Testing and have signed up for a SCRUM Master Certification class in July) and my background has been from the front to the back of the SDLC as a Business Analyst, Design Analyst QA Manager, and QA Analyst. My last position as a QA Manager I also served as a BA when needed and wrote shorter requirement documents as I worked closely with the developers to flush out the requirements.
In the Agile world after you have documented the ‘who’, ‘what’, and ‘why’ using User Stories, does the team then split up and discuss the list to see if there are any additional requirements or documentation needed? I know the sprints are short – 1 to 4 weeks long so I’m wondering how much time does a BA get to draft a document and what format does that take?
Thanks for your time to answer my questions.
This is a great question, Paula, and “it depends” on the organization, the project and the team. BAs typically work a sprint ahead of the next sprint to make sure the next -up user stories on the backlog are understandable and sized appropriately for the (development) team to estimate and plan what can be delivered (as working software) for the next sprint. Agile/Scrum does not prescribe any particular type of techniques or requirements documentation so that is where an experienced BA can propose what would is beneficial and appropriate for the team. Agile also does not prescribe that the role of a BA is needed but the skill set of business analysis is needed and therefore senior business analysts can really contribute on agile projects.
Paula,
User stories are commonly used as placeholders for further conversation and as a result are great for planning and scoping discussions, but woefully inadequate as complete description of the problem and possible solutions.
I encourage the teams I work with to follow an approach where shortly before a story is due to be delivered (say an iteration before) a deep dive is done into the story and a the resulting information is contained in appropriate models and a set of acceptance criteria. These acceptance criteria appear in the form:
GIVEN
WHEN
THEN
These are often in the form of real life examples that serve to clearly explain the intent of the story and provide a clear idea of how to confirm that the story was delivered properly (ie testing)
Hope that helps.
Kent