User Stories

Agile ,

User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
What is a user story?
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >.

User stories

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Important considerations for writing user stories:

1. 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 stakeholders) write them.
2. Use the simplest tool. User stories are often written on index cards.
3. Remember non-functional requirements. Stories can be used to describe a wide variety of requirements types. 
4. Indicate the estimated size.  One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point; therefore the user story in Figure will take around 10 hours to implement.
5. Indicate the priority. Requirements, including defects identified as part of your independent parallel testing activities or by your operations and support efforts, are prioritized by your project stakeholders (or representatives thereof such as product owners) and added to the stack in the appropriate place. You can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate. 
6. Optionally include a unique identifier. The card also includes a unique identifier for the user story, in this case 173. The only reason to do this would be to do this is if you need to maintain some sort of tractability between the user story and other artifacts, in particular acceptance tests.

User Stories and Planning

There are two areas where user stories affect the planning process on agile projects:

Scheduling. the agile change management management process where work items, including stories, are addressed in priority order. So, the implication is that the priority assigned to a story affects when the work will be done to implement that requirement. Project stakeholders are responsible for prioritizing requirements.Stakeholders also have the right to define new requirements, change their minds about existing requirements, and even re prioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner.

Estimating. Developers are responsible for estimating the effort required to implement the things which they will work on, including stories. The implication is that because you can only do so much work in an iteration, the size of the work items (including stories), affect when those work items will be addressed. 

Large stories: called epics, would need to be broken up into smaller stories to meet this criteria.

Initiatives: are collections of epics that drive toward a common goal.

Themes: are large focus areas that span the organization.