Ultimately, User Stories should be small. But when they’re first entered on the Product Backlog, when they’re quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.

Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.

The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:

* Independent. Okay, for some systems, it’s near impossible to make each feature completely independent. In other solutions, e.g. web sites, it’s easier. But it’s an important aspiration. User Stories should be as independent as possible.

* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

* Estimable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

* Small. User Stories should be small. Not too small. But not too big!

* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

This article reminded me about one user story that was once presented to me as an example. In this case the user were prospects at a trade show that would need a demonstration of a hypothetical company’s yet-to-be-completed software product. So given a limited time to include the features of the product in a demo, what do you include.

Almost everyone thought that a login would be necessary, which seems like a logical starting point. However, for the purposes of a demo, it really isn’t that necessary. It is not exactly a feature you want to show off. Much better to focus on features that will impress and bypass the login.

I am an international grad student in the U.S. and I am taking the agile management for project managers class this term. I am learning a lot of new things from both school and online. Agile is very different from traditional project management. I have used user stories for the first time in the class, and I found using them very useful. It is very simple way to delivery information or learn what users’ expectations are. This small piece of paper definitely improves the communication between the project ownership, team and end users. Or it helps to make things clear.
The first question came to my mind is why traditional project management does not borrow this simple tool from Agile. I know I am not the first person who would think of this but the idea of user stories can be used in traditional project management. For example, the project manager would use something similar to user stories to develop a risk register.
I don’t know if someone else have tried to use the idea of user stories in traditional project management but I would like to hear from your opinion about adopting this simple communication tool to the traditional project management. I also think that there are many agile tools that be used in the traditional project management.