Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


What are User Stories?


Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do.  User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application.  They describe the users’ goals when using the system.  The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical).   This isn’t the entire user story, but it is all that is created at first.  

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

  • The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development.  If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories.  The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
  • The Conversation:  While the conversation itself is not an actual deliverable, it is a critical step in the user story development process.  Discussions about each user story are had with the users/customers of the system to flesh out details.  The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
  • The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented.  When index cards are used, the acceptance tests are typically written on the back of the card itself.  Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal.  If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

  • I want to post a resume  
  • I want to search for a job
  • I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others.  One formal approach suggested by Mike Cohn follows the structure:  “As a (role) I want (something) so that (benefit)”.  At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

  • As a job seeker I want to post my resume so that recruiters and employers can find it.
  • As a job seeker I want to search for a job so that I’m in control of my job search.
  • As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

  • Test with keyword, salary, and location search parameters
  • Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.

Size and Scope User Stories have limited scope to fit within an iteration.  Use Cases are almost always larger in scope than user stories.
Structure User Stories typically represent a single scenario or path through a use case.  This could be the main scenario, or an alternative or extension path.  Remember that the user story includes the acceptance tests which often describe the details covered in alternative and extension flows. Use Cases represent a series of related user scenarios.  While a main scenario (often the most common scenario) is selected, there are many decision points throughout the flow that branch into alternative or exception flows.
Purpose User Stories are created to facilitate conversation between the client and development team when the time is right, and have the primary purpose of supporting release and iteration planning process. They are never referred back to as a contract between teams. Use Cases are written to be understood by both the client and the technology team.  They represent a written contract of the desired functionality.  
Completeness User Stories are intentionally written at a goal level initially with just enough detail to describe the user story with just a few sentences at most.  Only once the iteration planning begins and more detail will be required the team has conversations to capture acceptance tests. Use Cases are completed in their entirety early in the analysis and design process.  Because of this there exists a natural urge by the customers to place screen specific elements in the use cases themselves, even though there is usually a very strong push by the technology team to try and avoid this. Inevitably the technology team rarely succeeds in keeping UI features out of the use cases.
Longevity Typically User Stories are not intended to live beyond the iteration in which they are developed.  Once the functionality has been developed they are discarded. Use Cases are often saved and become permanent artifacts representing a permanent contract between the customer and development team.
Chris Adams
LinkedIn Profile



manujak posted on Tuesday, April 30, 2013 11:01 AM
can i have a sample user story templates
vt posted on Saturday, July 13, 2013 4:29 AM
good point however i don;t agree that story cards discarded once it;s developed. I feel it still represent as some kind of contract between client and supplier. If at later point of time, client asks why it's developed then supplier can very well referred the relevant story cards. we used to maintain all story cards from each sprint and generally refer it in contract.

please comment why you think that story card can be discarded...

Chris Adams posted on Monday, August 5, 2013 6:47 PM

Agile methodologies are implemented differently throughout the industry. The comment about discarding the cards makes for an interesting discussion. In many agile circles, the code is the spec. So once the cards are used to implement features in an iteration there is no need for the cards any longer.

However, I know of teams that keep the cards for later reference. But this leaves the question "is the card up to date". It implies that as new iterations occur that older cards are modified based on changes to features. I'm curious if in your experience you've encountered teams that actively manage an update cards on an ongoing basis. If so, how are the cards managed and organized such that you can be sure that you have identified all of the necessary impacts to cards?

Chris Adams
Anna posted on Wednesday, March 9, 2016 1:33 PM
Does User Story approach assume existing of any documentation describing system requirements? Is the only sourse of information is code? How can team members (especially new comers) or maybe clients as well get familiar with the system functionalities, logic and requirements without any documentation? Is it viable to combine user stories approach with supporting documentation?
Thank you in advance.
Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC