Agile Project Management
User Stories Extended
Slide 1: Understanding User Stories in Agile
User Story Basics
User Stories are short, simple descriptions of a feature or functionality as 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 [an action/goal] so that [a benefit/reason].
User Stories focus on user needs and desires.
They are short, simple descriptions of a desired feature.
They follow a simple template: As a [type of user], I want [an action/goal] so that [a benefit/reason].
2
Slide 2: Components of a User Story
The Three C’s of a User Story
Card: This is the written story, usually on a physical or digital card.
Conversation: This is the discussion about the story's needs.
Confirmation: This is the acceptance criteria or definition of 'Done.'
User Stories comprise of three main parts: Card, Conversation, and Confirmation.
The Card is the written user story.
The Conversation is the discussion around the story for further clarification.
The Confirmation is the acceptance criteria or definition of 'Done.'
3
Slide 3: Estimating User Stories
User Story Estimation Techniques
Planning Poker
T-Shirt Sizes
Dot Voting
The Bucket System
User Story estimation helps gauge effort, complexity, or size of the user story.
Common estimation techniques include Planning Poker, T-Shirt Sizes, Dot Voting, and The Bucket System.
4
Slide 4: Planning Poker in Detail
Step-by-Step Process of Planning Poker
Each team member is given a set of cards with numbers representing the Fibonacci sequence (1, 2, 3, 5, 8, 13...).
A user story is presented, and team members discuss it briefly.
Each team member selects a card that represents their estimate of the story's complexity.
All cards are revealed at the same time.
If estimates vary widely, a discussion is facilitated to understand different perspectives.
The process is repeated until the team reaches consensus.
Planning Poker involves team members estimating the complexity of a task using cards representing the Fibonacci sequence.
A user story is presented, discussed briefly, then independently estimated by each team member.
If estimates vary widely, further discussion takes place until consensus is reached.
5
Slide 5: Example of User Story Estimation
As a customer, I want a password reset function so that I can access my account if I forget my password.
Planning Poker Estimation
Team discussion about the user story.
Each member selects a card: 3, 5, 3, 5, 3, 3.
All cards are revealed - most members have chosen 3, a couple have chosen 5.
Discussion facilitated around why some members chose 5 - they explain potential complexities they foresee.
Repeat the process - final consensus is 3.
An example of Planning Poker using the user story, "As a customer, I want a password reset function so that I can access my account if I forget my password."
Team members independently estimate, reveal their estimates, discuss if necessary, and repeat the process until consensus is reached.
6
Slide 6: Importance of User Story Estimation
Helps in prioritizing user stories.
Provides a rough idea of when work can be delivered.
Facilitates better understanding of user stories among team members.
Enables more accurate sprint planning.
Estimation helps prioritize user stories.
It provides an idea of when work can be delivered.
It improves team understanding of user stories.
It enables more accurate sprint planning.
7
Slide 1: Real-Life User Story
User Story for a Social Media App
"As a user, I want to be able to upload photos on my profile so that I can share my experiences with friends."
This example showcases a feature for a social media app.
The user story is a clear expression of the user's need: uploading photos to their profile.
It describes the functionality from the user's perspective and gives context by providing the benefit (sharing experiences with friends).
8
Slide 2: User Story Breakdown
Breaking Down the User Story
User (Who): App User
What (What): Upload photos on their profile
Why (Benefit): Share experiences with friends
The breakdown of the user story helps to understand its different parts: the user (app user), the functionality (uploading photos to profile), and the reason or benefit (sharing experiences with friends).
9
Slide 3: Discussing the User Story
Discussion Points
What formats should the photos be in?
What is the maximum file size allowed for each photo?
How many photos can be uploaded at once?
How should errors be handled (e.g., unsupported file type, too large file size)?
Before estimating the user story, the team discusses various aspects to clarify the story.
This discussion can include technical requirements like file formats and sizes, number of photos that can be uploaded at once, and error handling strategies.
These understandings help provide a more accurate estimate.
10
Slide 4: Estimating the User Story - Planning Poker
Planning Poker Round 1
Team Member A: 8
Team Member B: 5
Team Member C: 8
Team Member D: 13
The team uses the Planning Poker technique to estimate the complexity of the user story.
Each team member independently chooses a card that signifies their estimate.
In this example, there's a variation in estimates: two members estimated an 8, one estimated a 5, and one estimated a 13.
11
Slide 5: Discussing the Estimates
Discussion on Variation
Team Member B (estimated 5) believes the feature is relatively straightforward as the app already supports file uploading in another area.
Team Member D (estimated 13) is concerned about potential complexities around error handling and the need to support multiple simultaneous uploads.
The team discusses the reasons behind the different estimates.
Team Member B thinks the feature is simpler due to existing functionalities in the app.
Team Member D is worried about potential complexities like error handling and supporting multiple uploads.
12
Slide 6: Estimating the User Story - Planning Poker (Round 2)
Planning Poker Round 2
Team Member A: 8
Team Member B: 8
Team Member C: 8
Team Member D: 8
After the discussion, the team does another round of Planning Poker.
All team members now agree on an estimate of 8.
The discussion helped to align everyone's understanding, leading to a consensus.
13
Slide 7: Conclusion - User Story Estimation in Practice
Estimation Outcome
Final estimation for the user story: 8
These discussions and estimations inform the prioritization and inclusion of this story in the next sprint.
The team reaches an estimation of 8 for the complexity of the user story.
This consensus helps to determine how the story fits into the product backlog and its prioritization for the next sprint
14
Slide 8: Reflection and Learning
Reflecting on the Estimation Process
Discussions provided clarity and unified understanding.
Variations in initial estimates brought out potential challenges.
Re-estimation led to consensus, emphasizing the importance of communication.
Reflection is crucial in Agile methodology.
Reflecting on this estimation process, the team acknowledges the role of open discussions in achieving clarity and shared understanding of the user story.
The variance in the initial estimates was valuable as it highlighted potential complexities that may have been overlooked.
The re-estimation process emphasizes the importance of communication in reaching consensus.
15
Slide 9: Moving Forward
Next Steps Post-Estimation
Include the user story in the sprint planning based on its priority.
Start working on the user story during the next sprint.
Monitor progress, and reassess the estimate if needed.
After the estimation, the team can move forward with the user story.
It will be incorporated into the sprint planning considering its priority among other stories.
During the sprint, the team will start working on the story. They should remember that the estimate is an educated guess of complexity and should monitor progress and reassess the estimate if the actual complexity during development varies.
This learning will feedback into improving future estimation accuracy.
16
Slide 7: Common Mistakes in User Story Estimation
Basing estimates on the 'best-case scenario.'
Not reassessing estimates when necessary.
Estimating too far in advance.
Letting one person dominate the estimation process.
Mistakes include basing estimates on the 'best-case scenario,' not reassessing estimates, estimating too far in advance, and allowing one person to dominate the estimation process.
17
Slide 8: Conclusion
User story estimation is a valuable tool in Agile methodology.
It helps to understand and communicate the complexity of user stories.
It facilitates more efficient sprint planning.
Though it has potential pitfalls, it becomes more accurate with practice and team familiarity.
User story estimation is a key tool in Agile methodology.
It helps communicate complexity and enables efficient sprint planning.
Despite potential pitfalls, accuracy improves with practice and increased team familiarity.
18