The document outlines an agile software development workshop focusing on user stories and estimation techniques. It covers key concepts such as the importance of user stories, the INVEST criteria for effective user stories, the process of breaking down epics into smaller user stories, and various estimation techniques like planning poker. Additionally, it emphasizes the collaborative nature of agile practices and offers practical exercises for participants to apply their learning.

1. Agile Software
Development Workshop
Focus on Creating User Stories and
Estimations
André Luís Pitombeira

2. Agenda
● Introduction to Agile Principles 5 min
● Understanding User Stories 5 min
● The INVEST Criteria for Good User Stories 15 min
● Breakdown of Epics into User Stories 10 min
● Introduction to Estimation Techniques 5 min
● Estimating User Stories 15 min
● Q&A and Wrap-up 5 min

4. Introduction to Agile Principles

5. What is Agile?
● Agile is a set of principles for software development under which
requirements and solutions evolve through collaborative effort
● Emphasizes flexibility, collaboration, and customer satisfaction
● Key agiles practices: iterative development, continuous feedback, and
adaptive planning

6. Importance of User Stories and Estimations
● User Stories: Capture needs and drive development
● Estimations: Provide a way to gauge the effort and time required to
deliver user stories
● Both are crucial for planning and delivering value in an Agile environment

7. Understanding User Stories

9. What Are User Stories?
● A user story is a simple, concise statement of a requirement or
functionality from the perspective of the end user
● Format: As a [type of user], I want [an action], so that [a benefit]

10. Components of a Good User Story
● User role: Who is the user?
● Action: What does the user want to do?
● Benefit: Why does the user want to do this?

11. Examples User Stories
● Example 1 As a customer, I want to be able to save items to a wishlist,
so that I can purchase them later
● Example 2 As a sales manager, I want to generate monthly sales
reports, so that I can track sales performance

12. The INVEST Criteria for Good User
Stories

13. What is INVEST?
● INVEST is a mnemonic to help ensure that user stories are well-crafted and
effective. Each letter stands for a key characteristic of a good user story:
○ Independent: The story should be self-contained, with no inherent dependencies on
other stories
○ Negotiable: The story is not a contract but a starting point for a conversation between
the team and the product owner
○ Valuable: The story must deliver value to the end user of the customer
○ Estimable: The story should be small enough to estimate with reasonable accuracy
○ Smal: The story should be small enough to be completed with a single iteration
○ Testable: There should be clear criteria to verify that the story has been implemented
correctly

14. Independent
● Poor Example: “As a user, I want to create an account, so that I can login and
manage my profileˮ
○ Problem: The story combines multiple actions (account creation, login, and
profile management) that are dependent on each other.
● Improved Example:
○ “As a user, I want to create an account, so that I can log inˮ
○ “As a user, I want to manage my profile, so that I can update my personal
informationˮ
○ Explanation: The stories are now independent and can be developed
separately

15. Negotiable
● Poor Example: “As a user, I want the system to generate reports with all possible
filters applied automaticallyˮ
○ Problem: This story is too rigid and detailed, leaving little room for negotiating
or adjustment based on technical constraints or user feedback.
● Improved Example:
○ “As a user, I want to filter my reports by key criteria, so that I can customize
the information I seeˮ
○ Explanation: The story focuses on the userʼs need while leaving room for the
team to discuss and negotiate the best way to implement the filtering
functionality.

16. Valuable
● Poor Example: “As a developer, I want to refactor the code, so that it is cleaner.ˮ
○ Problem: While this might be important for technical reasons, it doesnʼt
directly deliver value to the end user.
● Improved Example:
○ “As a user, I want the system to load my dashboard faster, so that I can
access my data quickly.ˮ
○ Explanation: This story is user-focused and clearly articulates the value to
the end user.

17. Estimable
● Poor Example: “As a user, I want to integrate the system with all external APIs, so
that I can have a unified view.ˮ
○ Problem: This story is too broad and complex, making it difficult to estimate
accurately.
● Improved Example:
○ “As a user, I want to integrate the system with the XYZ API, so that I can
retrieve real-time data.ˮ
○ Explanation: The story is specific and focused, making it easier to estimate.

18. ● Poor Example: “As a user, I want to manage all aspects of my account settings, so
that I can control my preferences.ˮ
○ Problem: This story is too large and likely to span multiple sprints.
● Improved Example:
○ “As a user, I want to change my password, so that I can keep my account
secure.ˮ
○ Explanation: The story is small and focused, making it possible to complete
within a single iteration.
Small

19. ● Poor Example: “As a user, I want the system to be user-friendly, so that I can have
better experience..ˮ
○ Problem: The term “user-friendlyˮ is vague and subjective, making it difficult
to test.
● Improved Example:
○ “As a user, I want a confirmation message after submitting a form, so that I
know my action was successful.ˮ
○ Explanation: The story includes clear, testable criteria (confirmation
message) to verify the implementation.
Testable

20. Exercise 1 Writing User Stories with INVEST
● Task: Write a user story based on the following scenario while ensuring it meets the
INVEST criteria:
● Scenario: A customer wants to receive notifications when flight prices drop on a
route they frequently travel.
● Instructions:
○ Write the user story using the format "As a [type of user], I want [an action], so that
[a benefit]."
○ Check your story against the INVEST criteria: Is it Independent, Negotiable,
Valuable, Estimable, Small, and Testable?
○ Be prepared to discuss how your story meets these criteria.

21. Exercise 1 Writing User Stories with INVEST  Answer
● User Story:
● As a frequent traveler, I want to receive notifications when flight prices drop on my selected routes, so that I
can book tickets at the best price.
● How This Story Meets the INVEST Criteria:
○ Independent:This story can be developed and tested independently of other stories, such as managing flight
bookings or setting up a user profile.
○ Negotiable: The details of how notifications are sent (e.g., email, SMS, app notification) can be discussed and
adjusted during the planning or refinement process.
○ Valuable: This story directly adds value to the user by enabling them to save money on flights, which is a clear
benefit to frequent travelers.
○ Estimable: The scope of the story is clear and specific, allowing the team to estimate the effort required to
implement the notification feature.
○ Small: The story is focused on a single feature (price drop notifications) and can be completed within a single
iteration or sprint.
○ Testable: The story is testable because the acceptance criteria can include checking that notifications are sent
when the price drops on a selected route. Test cases can be written to verify that the notifications are triggered
correctly.

22. Breakdown of Epics into User Stories

23. Breakdown of Epics into User Stories
● What Are Epics?
○ Epics are large user stories that can be broken down into smaller,
more manageable user stories.
○ An Epic usually represents a significant piece of functionality.

24. Breaking Down Epics
● Example Epic: "As a user, I want to manage my account settings."
● Breakdown into User Stories:
● As a user, I want to update my email address, so that I can receive
notifications.
● As a user, I want to change my password, so that I can keep my account
secure.
● As a user, I want to manage my payment methods, so that I can control
how I pay.

25. Exercise 2 Break Down an Epic
● Task: Break down the following Epic into smaller user stories:
● "As a project manager, I want to monitor project progress."
● Hint: Think of specific actions the project manager might take to monitor
progress.

26. Exercise 2 Break Down an Epic - Answer
● User Story 1:
● As a project manager, I want to view a dashboard showing the overall project status, so that I
can quickly assess project health.
● Explanation: This story focuses on providing a high-level overview of the project, enabling the
project manager to monitor the status at a glance.
● User Story 2:
● As a project manager, I want to track the completion status of individual tasks, so that I can
identify any potential delays.
● Explanation: This story allows the project manager to drill down into specific tasks, helping
them understand where bottlenecks might occur.
● User Story 3:
● As a project manager, I want to receive notifications when a task is delayed, so that I can take
action to keep the project on track.
● Explanation: This story adds a proactive feature, allowing the project manager to be alerted to
issues as they arise.

27. Exercise 2 Break Down an Epic - Answer
● User Story 3:
● As a project manager, I want to receive notifications when a task is delayed, so that I can take
action to keep the project on track.
● Explanation: This story adds a proactive feature, allowing the project manager to be alerted to
issues as they arise.
● User Story 4:
● As a project manager, I want to generate detailed progress reports, so that I can share project
updates with stakeholders.
● Explanation: This story focuses on reporting, providing a way for the project manager to
communicate project status with others.

28. Exercise 2 Break Down an Epic - Answer
● User Story 5:
○ As a project manager, I want to view the allocation of resources across tasks, so that I can
ensure the project is appropriately staffed.
○ Explanation: This story allows the project manager to monitor resource usage, ensuring that
no one is over or underutilized.

29. Introduction to Estimation
Techniques

31. Why Estimations Matter
● Estimations help in planning, managing resources, and setting realistic
expectations.
● How long a story will take (effort)
● Influenced by complexity, uncertainty, risk, volume of work
● Relative values are what is important
○ Login screen is 2
○ Checkout screen is 8

32. Challenges with Estimation
● Ambiguous/changing requirements
● Estimating takes too long and still donʼt get it right
● Estimations are provided by the wrong people
● Software projects are unique and ambiguous.
○ Hard to provide exact estimates
○ Exponential complexity
● Estimations are not commitments

33. Common Estimation Techniques
● Planning Poker: Collaborative estimation technique using cards with
story points.
● T-shirt Sizing: Estimates are expressed as sizes S, M, L, XL instead of
numbers.
● Complexity Bucket: Categorize tasks into predefined "buckets" based
on their complexity level. E.g, Low Complexity, Medium Complexity,
High Complexity

34. Why Planning Poker is Effective
● Collaborative: Involves the entire team, ensuring diverse perspectives.
● Shared Understanding: Discusses user stories to uncover hidden
complexities.
● Bias Mitigation: Independent estimates prevent anchoring bias.
● Relative Estimation: Focuses on comparing complexity, not time.
● Consensus Building: Encourages discussion until agreement is reached.
● Engaging: Fun and interactive, boosting team morale.

35. Tips for Reliable Planning Poker Estimations
● Clear User Stories: Ensure well-defined stories with clear acceptance criteria.
● Break Down Large Stories: Split complex stories into smaller, manageable ones.
● Consider All Work: Include coding, testing, integration, and documentation.
● Discuss Dependencies/Risks: Identify potential blockers or technical challenges.
● Factor in Team Experience: Adjust estimates based on team familiarity with the
task.
● Use Historical Data: Reference past projects to inform current estimates.
● Add Buffers: Account for uncertainties with a buffer in estimates.
● Encourage Discussion: Explore reasons behind widely varying estimates.
● Stay Consistent: Use a consistent scale like the Fibonacci sequence.
● Review and Adjust: Regularly refine estimates as more information becomes
available.

37. Story Points
● Abstract unit of time
○ Depending on the person it can be hours, days, weeks
● The goal is to take us away from thinking in terms of absolute
estimates
● Start doing estimates relatively

38. Story Points
● Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21
● Why does it work?
○ Weberʼs law state that the difference we can identify between objects is given by a
percentage
○ Each Fibonacci number is about 60% larger than the preceding value
○ According to Weberʼs Law, if we can distinguish a 60% difference in efforts between two
estimates, we can distinguish that same percentage between other estimates

39. Story Points Triangulation

40. Estimating User Stories

41. Example Scenario
● Initial User Story: "As a user, I want to upload and share documents, so
that I can collaborate with my team."
● Without Following the Tips:
○ Story Points: 5 points, assuming a straightforward file upload feature.

42. Example Scenario: After Applying the Tips
● Clear User Stories: The team clarifies that sharing involves permissions and
version control.
● Break Down Large Stories: The story is split into “Upload documentsˮ and
“Manage document sharing permissions.ˮ
● Consider All Work: They include integration testing and UX design.
● Discuss Dependencies/Risks: Integration with cloud storage introduces risks.
● Factor in Team Experience: The team is less familiar with the cloud storage API.
● Final Story Points: The original 5 points are now split into two stories:
○ "Upload documents" 5 points)
○ "Manage sharing permissions" 8 points)

43. Exercise 3 Estimating User Stories Using Planning Poker
● Task: Estimate the following user story using Planning Poker:
○ User Story: "As a user, I want to upload and share documents in multiple
formats, so that I can collaborate with my team."
● Instructions:
○ Step 1 Review the user story and discuss possible challenges (e.g., handling
different file formats, ensuring security, user interface).
○ Step 2 Each team member chooses an estimate considering complexity and
effort.
○ Step 3 Reveal the estimates and discuss any discrepancies.
○ Step 4 Reach a consensus on the final estimate.

44. Questions?

45. References 📚
● Succeeding with Agile: Software Development Using Scrum
● User Story Mapping: Discover the Whole Story, Build the Right
● User Stories Applied: For Agile Software Development
● Extreme Programming Explained: Embrace Change
● Software Estimation Techniques

46. Thanks for listening!
46
Questions or feedback?
Reach out to
André Pitombeira
Engineering Manager