Writing user stories can be fun yet challenging. The need for user stories arises as soon as a company realizes the software needs updates or changes. The software owner must be involved in determining what the software does now and what it needs to do in the future.
The owner must be guided by what stakeholders wish to do with the software and how it needs to serve clients and customers. His or her users are in invaluable source of ideas for necessary software changes.
Agile creates its own “work orders” through user stories. These simple narratives are just what the title implies: stories of what users require from the software for themselves and others they are connected with. Correctly writing a user story is vital to the BA process.
The user story is a simple cause / effect statement. The user, client, or customer needs the software to do X so he or she reaps the benefit Y. When the BA writes the user story, he or she will fill in the how-to’s: what changes the software appears to require, how the Agile team will employ the changes, how many iterations are expected, and how the team will know changes are correct and successful.
User stories define functionality requirements, desired features, and needs of stakeholders. Stories are not long, nor do they contain extensive detail. Users are interviewed or asked about their criteria. Acceptance requirements identify specific details about the user story and give the team guidance in how to proceed.
According to the Agile Extension of the BABOK® Guide, user stories are used to:
Prioritize work into iterations
Identify risk associated with a request
Estimate effort required to deliver request
Establish conversation between the team and the product owner around the subject of the real business need, in order to confirm a common understanding of what has to be done.
What do you do with your user stories when you begin your work? How important are they to you?