In projects i often see that there is still a lot of confusion about User Stories and planning. This article of the famous Scott Ambler describes the way you should plan and use User Stories within Agile projects. One common mistake is that a User Story is much smaller than a Use Case.
Introduction to User Stories
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.Initial User Stories (Informal)
As you can see in Figure 1 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 in Figure 1 represents a single user story.Figure 1. Example user stories.
|
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 as you see in Figure 2 (at least when your project team is co-located). Index cards are very easy to work with and are therefore an inclusive modeling technique.
- Remember non-functional requirements. Stories can be used to describe a wide variety of requirements types. For example in Figure 1 the Students can purchase parking passes online user story is a usage requirement similar to a use case whereas the Transcripts will be available online via a standard browser is closer to a technical requirement.
- Indicate the estimated size. You can see in Figure 2 that it includes an estimate for the effort to implement the user story. 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 2 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. You can see that the user story card includes an indication of the priority; I often use a scale of one to ten with one being the highest priority. Other prioritization approaches are possible – priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it’s own unique priority order number (e.g. 344, 345, …). You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. My advice is to keep it simple.
- 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 traceability between the user story and other artifacts, in particular acceptance tests.You can read the full article here
Reacties
Een reactie posten