User stories, epics, initiatives, and themes
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:
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.
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts.
user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios. It's important to recognize that each of the statements represents a single user story.
Important considerations for writing user stories:
- 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.
- Use the simplest tool. User stories are often written on index cards.
- Remember non-functional requirements. Stories can be used to describe a wide variety of requirements types.
- 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.
- 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.
- 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.
User Stories Throughout the Agile Life Cycle
There are several distinct "phases" agile cycle. There are three common times when stories will be worked on during an agile project:
Inception. You often create a stack of user stories during Inception as part of your requirements envisioning activities to identify the scope of your system.
Construction. During construction iterations you will identify new stories, split existing stories when you realize that they're too large to be implemented in single iteration, re prioritize existing stories, or remove stories that are no longer considered to be in scope.
Transition. Sometimes new stories will be identified during the Transition phase, these stories would be prioritized and placed on the stack in priority order.
Construction. During construction iterations you will identify new stories, split existing stories when you realize that they're too large to be implemented in single iteration, re prioritize existing stories, or remove stories that are no longer considered to be in scope.
Transition. Sometimes new stories will be identified during the Transition phase, these stories would be prioritized and placed on the stack in priority order.
Post a Comment