So...What's the Difference Between User Stories and Traditional Requirements?
Written by: Dan Tousignant
This question came from a webinar I recently co-hosted for Management Concepts.
This is a simple question for Agilista’s but an an appropriate question for those of you who are new to Agile. At Management Concepts, I teach a course on Agile Project Management for the Federal Environment.
For the purpose of the federal audience, I want to step back and define what a traditional set of requirements are. Typically, traditional requirements are text-based requirements such as a business requirement document or functional specifications. They typically describe in detail what the business is expecting the IT department or vendor to provide. There are other types of the requirements which are less text based such as Use Cases, Wireframes for screen designs, and workflow-type of requirements called UML. They are written at the beginning of the project, and they are at an exacting level of detail. Many Agile teams remain using these types of requirements especially if they are slowly transitioning to Agile.
User Stories take a very different, extremely simple, approach. In the most simplistic version, a User Story, which is an Agile business requirement, is captured on an index card. It is presented as a conversation between the user and the developer.
On the front of the card is
“As a <role>, I want <goal/desire> so that <benefit>“
or even more simply ….
“As a <role>, I want <goal/desire>“
Stakeholders write user stories. An important concept is that your project stakeholders write the user stories, not the developers. User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the users) write them. Some examples of user stories are:
- As an administrator, I want to be able to reset passwords for any user
- As customer, I want to be given alternatives if what I am searching for is not found
- As a customer, I want to be alerted if someone changes a file I created
- As a user, I want to search for my customers by their first and last names.
Remember non-functional requirements also. For example, as an end user, I want the application to work with IE, Firefox and Safari.
Another type of user story is called an Epic. Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.
One of the key principles of Agile is maximizing the work “not done”. User stories are the embodiment of this principle. They tell the developer only what value the business user is looking for. By not going into excruciating detail and allowing the developer to determine a solution, there is less wasted development effort. A user story first goal is be complete enough for the development team to perform relative sizing, in other words, develop an estimate. If more detail is needed later, then the stakeholder needs to be available throughout the iteration or Sprint for further discussion.
User Story development can be as simple as what I’ve described if the organization is aligned for Scrum. I have included a link to a user story card template if you are interested in seeing one or using it for your team. Good luck, and be patient. As with any Agile method, be iterative and inspect and adapt your process until you are happy with the results.
