The technique of expressing requirements as user stories is one of the most broadly applicable techniques introduced by the agile processes. User stories are an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects.
In this session, we will look at how to identify and write good user stories. The class will describe the six attributes that good stories should exhibit and present thirteen guidelines for writing better stories. We will explore how user role modeling can help when gathering a project's initial stories.
Because requirements touch all job functions on a development project, this tutorial will be equally suited for analysts, customers, testers, programmers, managers, or anyone involved in a software development project. By the end of this tutorial, you will leave knowing the six attributes of a good story, learn a good format for writing most user stories, learn practical techniques for gathering user stories, know how much work to do up–front and how much to do just–in–time.
Balance is critical (business and development)
- Technical vs business issues in focus
Resource allocation should be a shared problem (business and development)
Imperfect schedules
- We cannot perfectly predict a software schedule
- If we can't perfectly predict a schedule, we can't say what will be delivered
So what do we do?
- We make decisions based on information we have, but do it often
- We make decisions throughout the whole project
UserStories - Three C's of Ron Jeffries
- Card - The basics of the US
- Conversation - The details, captured in conversations with product owner
- Confirmation - Acceptance tests confirm the story was coded correctly. Defined by Product Owner in cooperation with team
Mike displayed UserStories examples
considers the "so that" clause as optional - use when needed to improve understanding, not when it is obvious
How to capture the detail?
Several options:
1. Write details as "conditions of satisfaction" - these are essentially tests, but we do not use this term (test) since it is misinterpreted by many..
2. Create a hierarchy with the details in sub-user stories
These techniques can and should be combined
Mental model for the product backlog as an iceberg with more detail/smaller items on the top (Sprints), bigger in the middle (Release), and large at the bottom (future releases)
Someone needs to regularly "grooming the product backlog". Estimated required effort for this activity is 10% of the entire team effort (preparing for the next sprint).
Introducing the concept of "Epic" (large user stories) and "Theme" (collection of user stories) to organize the backlog.
Writing user stories exercise.
Topic is Logging in:
As a registered user, I want to be able to get my existing username and password via email in case I forget it
As a registered user, I want to be able to get my existing username and password via sms in case I forget it
As a registered user, I want to be able to enter my username and password so that I can access the system
As a new I want to be able to register as user in the system
As a new I want to be get an email confirmation with my chosen username and password, when I have successfully registered
Mike: Its ok to write user stories that convays the meaning, but are not "true" (e.g. As a user I want the bank to debit my account when I withdraw money from the ATM)
Arrange User Story Workshops
- Product Owner + team members
Start with Epics and iterate
Why User Stories
- Shift the focus from writing to talking (avoid "you built what I asked for (as written in the spec) but it is not what I need"). This does not imply not writing things down!.. only to include
- Stories are equally understandable by developers and customers
- Stories support and encourage iterative development
- Stories are the right size for planning
- Stories support participatory design - get as close to users as possible
- Stories emphazise the users goals not the system's attributes (example with Car vs Lawn Mover)
Most importantly: Don't forget the purpose. The story text we write on the card is less important than the conversations we have
Q&A
Q: How to incorporate bugs into this process?
A: Some teams pull work from two queues, and then uses Stories to "wrap" bugs.
Consolidating tools is a good thing in this process (e.g. not a separate bug tracking tool from the UserStory tool)
Balance is critical (business and development)
- Technical vs business issues in focus
Resource allocation should be a shared problem (business and development)
Imperfect schedules
- We cannot perfectly predict a software schedule
- If we can't perfectly predict a schedule, we can't say what will be delivered
So what do we do?
- We make decisions based on information we have, but do it often
- We make decisions throughout the whole project
UserStories - Three C's of Ron Jeffries
- Card - The basics of the US
- Conversation - The details, captured in conversations with product owner
- Confirmation - Acceptance tests confirm the story was coded correctly. Defined by Product Owner in cooperation with team
Mike displayed UserStories examples
considers the "so that" clause as optional - use when needed to improve understanding, not when it is obvious
How to capture the detail?
Several options:
1. Write details as "conditions of satisfaction" - these are essentially tests, but we do not use this term (test) since it is misinterpreted by many..
2. Create a hierarchy with the details in sub-user stories
These techniques can and should be combined
Mental model for the product backlog as an iceberg with more detail/smaller items on the top (Sprints), bigger in the middle (Release), and large at the bottom (future releases)
Someone needs to regularly "grooming the product backlog". Estimated required effort for this activity is 10% of the entire team effort (preparing for the next sprint).
Introducing the concept of "Epic" (large user stories) and "Theme" (collection of user stories) to organize the backlog.
Writing user stories exercise.
Topic is Logging in:
As a registered user, I want to be able to get my existing username and password via email in case I forget it
As a registered user, I want to be able to get my existing username and password via sms in case I forget it
As a registered user, I want to be able to enter my username and password so that I can access the system
As a new I want to be able to register as user in the system
As a new I want to be get an email confirmation with my chosen username and password, when I have successfully registered
Mike: Its ok to write user stories that convays the meaning, but are not "true" (e.g. As a user I want the bank to debit my account when I withdraw money from the ATM)
Arrange User Story Workshops
- Product Owner + team members
Start with Epics and iterate
Why User Stories
- Shift the focus from writing to talking (avoid "you built what I asked for (as written in the spec) but it is not what I need"). This does not imply not writing things down!.. only to include
- Stories are equally understandable by developers and customers
- Stories support and encourage iterative development
- Stories are the right size for planning
- Stories support participatory design - get as close to users as possible
- Stories emphazise the users goals not the system's attributes (example with Car vs Lawn Mover)
Most importantly: Don't forget the purpose. The story text we write on the card is less important than the conversations we have
Q&A
Q: How to incorporate bugs into this process?
A: Some teams pull work from two queues, and then uses Stories to "wrap" bugs.
Consolidating tools is a good thing in this process (e.g. not a separate bug tracking tool from the UserStory tool)
No comments:
Post a Comment