際際滷

際際滷Share a Scribd company logo

Introduction to Agile Software Development

A
Andr辿 Pitombeira

This presentation explores the fundamentals of Agile practices with a focus on crafting effective user stories. Learn how to apply the INVEST principle to ensure your user stories are independent, negotiable, valuable, estimable, small, and testable, driving better collaboration and delivering clear value to your projects.

1 of 46
Download to read offline
Agile Software Development Workshop Focus on Creating User Stories and Estimations Andr辿 Lu鱈s Pitombeira
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
Introduction to Agile Software Development
Introduction to Agile Principles
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
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
Understanding User Stories
Introduction to Agile Software Development
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]
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?
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
The INVEST Criteria for Good User Stories
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
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
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.
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.
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.
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
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
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.
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.
Breakdown of Epics into User Stories
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.
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.
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.
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.
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.
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.
Introduction to Estimation Techniques
Introduction to Agile Software Development
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
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
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
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.
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.
Introduction to Agile Software Development
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
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
Story Points Triangulation
Estimating User Stories
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.
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)
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.
Questions?
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
Thanks for listening! 46 Questions or feedback? Reach out to Andr辿 Pitombeira Engineering Manager

More Related Content

Introduction to Agile Software Development

  • 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
  • 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
  • 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.
  • 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
  • 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.
  • 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