Boost Agile » Blog » Why user stories aren’t use cases – Part 2

Boost agile blog

Why user stories aren’t use cases – Part 2

Posted by on 14 May, 2012

In part 1 of Why user stories aren’t use cases, we looked the differences between user stories and use cases. Now we’ll look at how user stories develop during the Scrum process to explain why user stories, though not the same as use cases, serve the same purpose. 

Acceptance criteria

In part 1, we looked at the format of user stories: As an actor I want action so that achievement. The product owner adds detail to that one sentence story by writing acceptance criteria. Acceptance criteria define the parameters of a user story and determine when a story is completed and working as expected. 

Here’s a user story: As a conference participant, I want to be able to register online, so I can register quickly and avoid unnecessary paperwork. Your acceptance criteria might include:

  • A user cannot submit a form without completing the mandatory fields
  • Information from the form is stored in a registrations database
  • Payment can be made via credit card or online banking
  • An acknowledgment email is sent to the user after the form is submitted.

Sprint planning meetings

Another opportunity to flesh out the detail of the user story arrives in the sprint planning meeting. 

At the meeting, the product owner presents the user stories with the highest priority functionality from the top of their product backlog. The team asks questions to clarify the user story and the acceptance criteria and to confirm or correct any assumptions.

Any further ambiguities surrounding the requirements quickly start to disappear as the team estimates the stories. Radical differences in estimation by team members indicates that there are further questions that need answering.  

The process is repeated as the team writes the individual tasks for each user story.

Speaking of meetings, if your product owner commits to attend the team stand-up, the team can ask questions here, too. In turn, the team can inform the product owner of any restrictions, issues and opportunities cropping up as the story develops.

Wireframing and development

Wireframing typically generates further questions of the product owner, as well as providing the basis for generating feedback from designers and developers as well as user testing. 

During development, there are often more queries and clarifications for the product owner about how they want the backend of the system to behave. Pair programming puts two sets of eyes on a piece of functionality, which means even more questions.

Day-to-day Scrum process

The Scrum process allows the detail of what is being built to emerge. Unlike use cases, which are written by one person up front, user stories emerge from the day-to-day work of the whole team, informed by the development as it progresses. 

Are there exceptions? One of our colleagues argues there can be instances where significant upfront research is necessary. All the same, her advice is don’t write use cases until your team asks for them. Even then, use a retrospective to reveal what it is that’s not working – it might be that the acceptance criteria are ambiguous or the product owner needs to attend stand ups, for example. You and the team might uncover a different problem that needs fixing.  

More reading

Mike Cohn: User stories aren’t use cases and Advantages of user stories for requirements

Andrew Stellman: Requirements 101: User stories vs use cases

Tags: Posted in: Agile, User Stories 0 comments