Agile for product owners v12
Download as PPTX, PDF0 likes116 views
Here are 3 scenarios that could be attached to the user story card: Scenario 1: As a customer, I search for flights from New York to Los Angeles for next weekend. The results show available flights for those dates. Scenario 2: As a customer, I select a flight from the results and am taken to a page to enter my personal details and payment information to complete the booking. Scenario 3: As a customer, I receive a confirmation email after completing my booking with all the flight details. Conversation The team discusses things like: - What dates constitute "next weekend"? - What payment methods will be accepted? - What information is included in the confirmation email? Confirmation
![36
Card
As a [role]
I want [feature]
so that [benefit]
Scenario 1: [scenario title]
• Given [initial context]
• When [event occurs]
• Then [ensure some outcomes]
Scenario 2: [another scenario title]
• Given [initial context]
• AND [another context]
• When [event occurs]
• Then [ensure some outcome]
• AND [ensure another outcome]
Confirmation (Acceptance Criteria)
Backlog Refinement: : BDD (Behavior Driven Development) Template](https://image.slidesharecdn.com/agileforproductowners-v12-201118173513/85/Agile-for-product-owners-v12-36-320.jpg)
![37
Backlog Refinement: Splitting (slicing) User Stories with AC’s (Scenarios)
As a [role]
I want [feature]
So that [value]
Acceptance Criteria
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
Notes: [discussion notes]
US.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 3
Scenario 4
Notes: [discussion notes]
US.01.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 5
Notes: [discussion notes]
US.01.02](https://image.slidesharecdn.com/agileforproductowners-v12-201118173513/85/Agile-for-product-owners-v12-37-320.jpg)
Agile for product owners v12
- 3. 3 Course Requirements Prerequisite • Prior to taking this training, you should have completed the following: • Agile 101 Training Intended Audience • Product/Service Owner • Business Analyst • Service Analyst • Any role involved in Requirement Elicitation and Management process
- 4. 4 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners2 Introduction to Product/Service Backloga Writing Good User Storiesb Writing Testable Acceptance Criteriac 1 Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 5. 5 What are Lean Principles? And How do we implement them in Agile Lean Principles Implementation in Agile Eliminate waste Retrospectives, Feedback loops at every iteration Amplify learning Retrospectives, Feedback loops at every iteration Decide as late as possible Iteration Planning every 2 weeks Deliver as fast as possible Short Iterations Empower the team Servant Leadership, Team Collaboration Build integrity in Build Quality In: Continuous Testing & integration See the whole Cross functional teams, breaking down Silos Principles Values Process Practices (kata)
- 6. 6 In Summary: Scrum is most common Agile Framework • Each sprint has a fixed duration “time-box” • Each sprint delivers working, fully tested code • Only the team can do a pull from backlog • Team cannot plan to exceed their capacity • Team sync up on sprint goals during daily standup • Core team size cannot be dynamic • Team stays together for extended duration Scrum is lightweight yet, like rugby, needs rules to ensure correct flow. It is the responsibility of the Scrum Master to ensure adherence to the agreed rules. Scrum Values Commitment, courage, focus, openness and respect
- 7. 7 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backloga Writing Good User Storiesb Writing Testable Acceptance Criteriac 2 Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 8. 8 Video #0: Product Owner Role Agile Product Ownership in a nutshell by Henrik Kniberg
- 9. 9 What is Role of Product/Service Owner? Accountable for maximizing the value of a product/service, by incrementally managing and expressing requirements for a product/service to the team Key Responsibilities include the following: Create Product/Service Vision and convey vision to the team Manage and Refine Product/Service Backlog Prioritize features according to market value Drive Release Planning Collaborate and Communicate with Stakeholders and End Users – Manage Expectations Demonstrate Return on Investment (ROI) Accept, reject or defer the “finished” work based on results
- 10. 10 A Day in Life of Product/Service Owner • Assist Team members to resolve issues or provide clarification • Review the implementation of each sprint backlog item as early as possible to confirm the results are as desired • Refine Epics/User Stories for future requirements • Conduct Product/Service Backlog Refinement sessions to prepare for next sprint planning • Explain the priority user stories to team • Answer questions to clarify requirements or resolve issues that affect implementation or estimation • Ensure team provides sprint commitment at the end of Sprint Planning session Sprint Planning During Sprint • Attend the Daily Scrum meeting as observer, wherever possible Daily Scrum • Reviews the user stories completed during the sprint • Provide feedback on implementation, if any • Formally accepts or rejects user stories planned for the sprint • May involve other stakeholders as necessary • Reviews release progress Sprint Review • Participate in sprint retrospective, if team desires Sprint Retrospective
- 11. 11 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 12. 12 Product/Service Backlog High priority Low priority Prioritized list of all work items, in form of Theme, Epics/Features, and User Stories which are classified as: New item, Tech Debt (shortcuts taken), Defect Debt (open defects) & Test Debt (pending test automation) Fine-grained Backlog Items ready for Future Sprints i.e. smaller user stories Medium-grained Backlog Items for Current Release Coarse-grained Backlog items for Future Releases • It is truly all things. If a thing is in there it might get done. If it isn’t there, then there is no chance that it will be done. • It represents opportunities, not commitments – a list of “what we want to do.” • Items may be estimated (preferable), but estimates do not imply committed delivery. • It has a single owner: Team’s Product/Service Owner
- 13. 13 Product/Service Backlog: Defines the “What” • “Theme” Over arching business capability or long lived business process e.g. Online banking • “Epic”, Business or architectural goals to be realized by the system or software. Can span multiple sprints in order to complete. e.g. Online Payment • “User Story” Meaningful unit of work that be completed by a team within a sprint – typically one distinct function. Should not span more than one sprint. e.g. Payment through credit card
- 14. 14 Product/Service Backlog: Three Primary Sources 1. Business Stakeholders Product/Service Backlog 3. Other Stakeholders Stories Epics • Other team dependencies • Other commitments • Spikes/Research 2. Team Context • Tech Debt (Refactoring) • Maintenance • Defect Debt • Test Debt (Automation) • Product Vision • Business Requirements
- 15. 15 Break #1
- 16. 16 User Story Map: Begin With End In Mind • Release Planning starts with User Story Mapping • Align stories as per user activity (2nd line)– helps with grouping the features (1st line) toward the activity • High value items at the top and low value items at the bottom • Stories (Product/Service Backlog) categorized by Releases (Release Backlog) • Incrementally realize the Product Goals optionality necessary less optional more optional Release 1 Release 2 Release 3
- 17. 17 User Story map Exercise • Identify an Epic from your current engagement (1 per group) • Create a user story map for 1 or 2 personas
- 18. 18 Break #3
- 19. 19 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 20. 20 User Stories- Why and What Why? Focus on value at a granular level Created specifically to link requirements with users Encourages visualisation rather than verbalisation Fundamental building block for any agile delivery mechanism Facilitates early return on investment, and feedback Demands consideration of vertical slicing + emergent design What? Method of capturing requirements that shifts focus from writing to talking Typically written in the format: as a {type of user} I want {some goal} so that {some value} Written by BAs/SAs with input from Product/Service Owners, Tech Leads, Developers, QA, Scrum Masters and/or other SMEs as defined by Product Management. According to Mike Cohn, a User Story “is an agreement to have a conversation in the future.”
- 21. 21 User Story Guidelines: Ron Jeffries’ “Three Cs*” *© Ron Jeffries Card Written on card/tool and may annotate with notes As a spouse I want a clean garage so that I can park my car and not trip on my way to the door. Conversation Details in conversation with Product/Service Owner What about the bikes? Oh yeah – hang the bikes. Confirmation Acceptance criteria confirm “correctness” of user story Tools have been put away Items are off the floor Bikes have been hung
- 22. 22 Card • User Stories are typically written in the format: As a {role} I want {some activity} so that {some value} A role can be a user, device or other system. As a policy holder, I want the customer support specialist to give a consistent, clear messages so that I can resolve my issues without needing additional support. As a Web crawler, I want a crawl constrained only to new URLs in the URL dictionary so that the crawling cycle can be completed quickly
- 23. 23 Conversation Product/Service Owner, stakeholders, developers, and testers communicate continuously to ensure maximum value delivered! • Conversation spans all steps in story lifecycle • Conversation provides shared context • Conversation drives requirements via scenarios • Conversation uncovers gaps in scenarios & NFRs (non-functional requirements) Conversation Shared Context STORY
- 24. 24 Confirmation As a consumer: I always see current energy pricing reflected on my portal so that I know that my energy usage costs are accurate and reflect any utility pricing changes Confirm using Acceptance Criteria: • The current pricing is always used and the calculated numbers are displayed correctly on the portal (see attachment for format) • The pricing and the calculated numbers are updated correctly when the price changes • The “current price” field itself is updated within the SLA time • The info / error message appears when there is an error or fault in the pricing (see attached approved error message for format) • Cover relevant aspects, including: • System Behavior • NFRs (non-functional requirements) • Are mainly defined during Sprint Planning, but also can be defined before (at Backlog Grooming Sessions), or after Sprints • Serve as a starting point for story acceptance tests
- 25. 25 I N V E S T Independent Negotiable Valuable Estimable Small Testable - Make stories as independent as possible from each other - Start with a brief description - Details emerge in discussion & negotiations - Users and customers perceive value in the deliverables - Domain and technical knowledge allow the team to provide estimates - A team can finish one story in a few days, and several in every sprint - Acceptance (testing) criteria and technique are specified clearly Summary: Invest in Writing Good User stories
- 26. 26 Life Cycle of a User Story Product/Service Owner PO + ARCH + LEAD PO + QA + LEAD PO + Team Product/Service Owner writes epics that are negotiable and has relevant business value Architect and Team Lead negotiate with PO/ SO to create vertical slices of epics to shape small and independent stories QA ensures stories are testable and estimable with scenarios for each user story Additional story split along scenarios and acceptance criteria may occur Team receives well packaged user stories Team negotiates user stories with the Product/Service Owner Team sizes story for understanding and provides estimate Negotiable Valuable Independent Small Estimable Testable
- 27. 27 Definition of Done: Accepting User Stories A User Story is accepted when it satisfies the Definition of Done (DoD) and is accepted by the Product/Service Owner Developers and testers stick to DoD, predefined criteria for backlog items DoD STORY STORY STORY STORY STORY Agile Team Product/Service Owner Product/Service Owner reviews Acceptance Criteria w.r.t. finished work and accepts/rejects/defers story
- 28. 28 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 29. 29 So Where are the Details? As a user, I can cancel a reservation so that I can get a refund • Does the user get a full or partial refund? • Is the refund to her credit card, or is it site credit? • How far ahead must the reservation be cancelled? • Is that the same for all hotels? • For all site visitors? Can frequent travelers cancel later? • Is a confirmation provided to the user? • How? Consider following story and possible questions about accepting that story:
- 30. 30 Details as Conditions of Satisfaction Product/Service Owner’s Conditions of Satisfaction can be added to a story. These can be added as “acceptance tests” to ensure done-done. As a hotel user, I can cancel a reservation…. • Verify that a Premium Member can cancel the same day without a fee. • Verify that a non-premium member is charged a 10% penalty for a same-day cancellation. • Verify that an email confirmation is sent. • Verify that the hotel is notified of any cancellations.
- 31. 31 Exercise #2: Decompose Epic “Send Money Using Mobile Devices” Activity: • An Epic will be provided to each group • Group needs to identify 3 user stories with acceptance criteria in 15 minutes • Group will write user stories in a format specified in the template below: • Each group will present 3 user stories AS A…… I WANT…. SO THAT….. ACCEPTANCE CRITERIA User A feature Business reason for doing it Conditions of satisfaction
- 32. 32 Exercise #2: Decompose Epic into User Stories from Story Map (Template) Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria Participate in user story grooming session to write 3 user stories from your Story Map As A: I want: So That: Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria As A: I want: So That: Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria As A: I want: So That:
- 33. 33 Exercise #3: Decompose Epic “Send Money Using Mobile Devices” (Example) Domain Banking Title Send Money Using iPhone Priority High Story Points ? Description Acceptance Criteria 1. I can use options for payment gateway 2. I can see hold on my credit/debit card Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using Android Priority Medium Story Points ? Description Acceptance Criteria 1. I can use options for payment gateway 2. I can see hold on my credit/debit card Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using BB Priority Low Story Points ? Description Acceptance Criteria 1. I can use options for payment gateway 2. I can see hold on my credit/debit card Dependencies Risks Non-functional Requirements Teams Participated in user story grooming session to come up with something like this: As A: I want: So That: iPhone User To send money I can buy stuff As A: I want: So That: Android User To send money I can buy stuff As A: I want: So That: BlackBerry User To send money I can buy stuff
- 34. 34 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 35. 35 Backlog Refinement: User Story Form • 2-3 sentences used to describe intent of the story • Summarizes intent and represents a more detailed requirement, whose details remain to be determined (which leads to…) • Recurrent discussion between the team, customer, Product/Service Owner, and other stakeholders • Attached to a user story as notes (which solidify…) • Represent the conditions of satisfaction • Written as scenarios Card Conversation Confirmation
- 36. 36 Card As a [role] I want [feature] so that [benefit] Scenario 1: [scenario title] • Given [initial context] • When [event occurs] • Then [ensure some outcomes] Scenario 2: [another scenario title] • Given [initial context] • AND [another context] • When [event occurs] • Then [ensure some outcome] • AND [ensure another outcome] Confirmation (Acceptance Criteria) Backlog Refinement: : BDD (Behavior Driven Development) Template
- 37. 37 Backlog Refinement: Splitting (slicing) User Stories with AC’s (Scenarios) As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Notes: [discussion notes] US.01 As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 3 Scenario 4 Notes: [discussion notes] US.01.01 As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 5 Notes: [discussion notes] US.01.02
- 38. 38 Backlog Refinement: How to “INVEST”? How do we slice a story into smaller ones? • Slice it just like the way you cut a cake to relish the flavors in all the layers: • Slicing your story vertically allows you: • Deliver complete business-driven functionality to the customer early and incrementally • Adapt architecture tasks based on changes from the customer • Easier to plan and to complete within a sprint • Enable feedback after each slice is completed
- 39. 39 Backlog Refinement: Decomposition Cheat Sheet • Rule of thumb: get the most value with the minimum effort • Choose the split that leads to the biggest difference in value. • Choose the split that leads to the smallest difference in size • Patterns for Decomposing Features into user stories 1. On operation boundaries 2. On business rules 3. On effort boundary 4. On complexity 5. On data types 6. On input methods 7. On requirement type 8. On workflow boundaries 9. On engineering activity 10. On architectural boundaries - this is your last resort, when nothing else works! Here are examples of patterns for feature decomposition into vertically sliced user stories: Please pre-load this cheat-sheet with sample user stories from your existing Product/Service Backlog. Put those sample stickies next to each decomposition pattern here!
- 40. 40 Backlog Refinement: Feature Decomposition Examples Pattern Original story Split stories Identify operational boundaries I'd like to manipulate posts on wiki I'd like to edit a post I'd like to share a post I'd like to delete a post Identify independent business rules I'd like to search for a post I'd like to find posts from a specific person I'd like to find posts sent or received in a specific date range I'd like to find posts pertaining to a certain topic I'd like to find posts linking to a certain post Perform what-if analysis to account for technical or scheduling dependencies and identify an effort boundary I'd like to see an up-to-date contact list in chat window I'd like to see an up-to-date contact list in my chat window: o need to poll server periodically o When notifications are implemented, we can leverage API Isolate the simple from the complex I'd like to share knowledge and information with others I'd like to quickly share mostly text and maybe a link, a-la Twitter I'd like to add embedded images and multimedia content to my posts I'd like to add references to external data to my post, updated on-the-fly Handle various data types separately whenever possible I'd like to ignore updates I am not interested in I'd like to ignore updates from a specific person I'd like to ignore updates in a specific community
- 41. 41 Backlog Refinement: Feature Decomposition Examples (Continued) Pattern Original story Split stories Provide the user with different ways to input data into the application I'd like the application to help me with the list of users I'm sharing a post with I'd like to be able to pick people from a list of contacts I'm most often in touch with I'd like to be able to search for people in the corporate directory I'd like the application to auto-complete a person's name as I am typing it. Separate functional and non-functional requirements I'd like to be able to attach files to a post I'd like to be able to attach multiple files to a post. It's OK if I have to add each one separately. I'd like an easy way to attach multiple files to a post. Multiple select, drag-and- drop or any other form is acceptable so long as I don't have to add each file separately. Identify workflow boundaries I'd like the system to assist me in creating a post When I add a post title, I'd like the system to look for similar posts and give me an option to comment or edit them instead so as to avoid effort duplication I'd like to link data from other posts into the post I am creating and have the system update it automatically Split out the research from the implementation I'd like to configure the application to my own taste As an engineer, I need a framework to handle user preferences so that I can make certain aspects of the application configurable As a user, I'd like to be able to set user preferences in order to configure the application the way I like it
- 42. 42 What about Non Functional Requirements (NFR)? • Non-Functional Requirements such as performance, robustness, scalability, usability, as well as technical and compliance requirements are treated as constraints: • Global Constraint: • Applies to all functionalities of the application. E.g. Performance of the application, federal/state regulatory requirements, etc. • Should be considered during road mapping or early backlog refinement phase. Late discovery of such requirement will impact the product success • Should be part of “Definition of Done” (DoD) • May exist as “Non-functional” story or requirement • Local Constraint: • Applies to some functionalities or stories within application. E.g. Constraint-The MasterCard charge transaction shall not be more than five seconds • Should be stated as Constraint and attached to the story
- 43. 43 In Summary: Product/Service Backlog Refinement • Gain understanding of Product/Service Backlog items and break down large items into smaller items • Ensures all Product/Service Backlog items are sized • Ensures Product/Service Backlog items are ordered to maximize product value over time • Ensures 1.5 – 2 sprints worth of items at the top of the Product/Service Backlog are “Sprint Ready” • Team looks further ahead and starts breaking down large items • Team should expect to spend 5-10% of each sprint helping refine the stories for the next sprint • Product/Service Owner removes any stories that have been towards the bottom of the Product/Service Backlog and will never be worked on
- 44. 44 Exercise #3: Refining User Stories with BDD template (GIVEN… WHEN… THEN…) Activity: • Regroup with same team members as for “Writing User Stories” exercise • Group now needs to review user stories identified earlier • Use INVEST criteria review and refining the user stories • Apply the 10 slicing techniques we discussed just now • If possible, use GIVEN…WHEN…THEN… style for acceptance criteria • Group needs to present the refined user stories
- 45. 45 Exercise #3: Refining User Stories with BDD template (GIVEN…WHEN…THEN…) Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria Participate in user story grooming session to refine user stories created earlier: As A: I want: So That: Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria As A: I want: So That: Domain Banking Title Priority High Story Points <ignore> Description Acceptance Criteria As A: I want: So That:
- 46. 46 Exercise #3: Refining User Stories with BDD template (Example) Domain Banking Title Send Money Using iPhone Priority High Story Points ? Description Acceptance Criteria 1. GIVEN Apple as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using Android Priority Medium Story Points ? Description Acceptance Criteria 1. GIVEN Square as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using BB Priority Low Story Points ? Description Acceptance Criteria 1. GIVEN PayPal as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Teams Participated in user story grooming session to come up with something like this: As A: I want: So That: iPhone User To send money I can buy stuff As A: I want: So That: Android User To send money I can buy stuff As A: I want: So That: BlackBerry User To send money I can buy stuff
- 47. 47 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 48. 48 Product/Service Backlog Management - Priority Drives the Planning Iteration / Sprint Release Priority High Low Roadmap Value Risk Cost Knowledge
- 49. 49 How to Prioritize Stories: MoSCoW Principle as an option MoSCoW – Prioritizes stories in four categories Must Have - Stories that must be included in the project delivery time-box for the project success Should Have - Stories not critical but should be included if at all possible Could Have - Less critical but nice to have stories Won’t Have - Least critical and lowest payback items • Appropriate mix of stories in each category can be implemented for a release/sprint • Example 50% can be Must have, 30% Should have, 15% Could have and 5% Wont have
- 50. 50 How to Prioritize Stories: Risk Analysis as the other option High Risk Low Value High Risk High Value Low Risk Low Value Low Risk High Value Value Risk Low High High Avoid Do first Do Last Do second Value Risk Low High High To optimally prioritize feature it is important to consider both risk and value Business Dimensions The desirability of the story to a broad base of users or customers The desirability of the story to a small number of important users or customers The cohesiveness and ordering of the stories in order to deliver the release end-goals Business seeks for advice from the technical team but if there is disagreement, Business might still push for the feature Technical Dimensions Technical Complexity Technical Feasibility The technical risk that the story cannot be completed as desired The impact the story will have on other stories if deferred (consider high risk story first)
- 51. 51 Exercise #4: Prioritizing User Stories Activity • Group now needs to prioritize user stories identified earlier based on value and risk factors • Group needs to present the prioritized user stories • Present the prioritized Product/Service Backlog
- 52. 52 Exercise #4: Prioritized User Stories (Example) Domain Banking Title Send Money Using iPhone Priority High Story Points ? Description Acceptance Criteria 1. GIVEN Apple as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using Android Priority Medium Story Points ? Description Acceptance Criteria 1. GIVEN Square as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Domain Banking Title Send Money Using BB Priority Low Story Points ? Description Acceptance Criteria 1. GIVEN PayPal as gateway WHEN user enters payment THEN Process payment 2. GIVEN card WHEN Pay THEN hold Dependencies Risks Non-functional Requirements Teams Participated in user story prioritization session to come up with something like this: As A: I want: So That: iPhone User To send money I can buy stuff As A: I want: So That: Android User To send money I can buy stuff As A: I want: So That: BlackBerry User To send money I can buy stuff 3 5 8
- 53. 53 Break #3
- 54. 54 Agenda Agile and Scrum Flow – A Recap Agile for Product/Service Owners 1 Introduction to Product/Service Backlog 2 Writing Good User Storiesb Writing Testable Acceptance Criteriac a Backlog Refinement Techniquesd Prioritization Techniquese Release Planning and Metricsf Working with the Customerg Scrum in Large Organizationsh
- 55. 55 Sizing Board: Teams Size the Stories from Story Map(s) • Use modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20 • Always triangulate with other stories – for example, an 8 point story should take 4 times longer than a 2 point story • Stories should be of similar sizes, to increase predictability while trying to reduce variability at the same time, e.g. 3, 5, 8
- 56. 56 Release Plan: Forecast, typically for Next Quarter • Based on: • Relative priority of backlog items • The size estimate given to each backlog item • Team velocity: baseline it with Known Velocity Trends • Release Plan is reflection of the Product/Service Backlog • Updated Continuously – at end of every sprint at least
- 57. 57 And How to Track Product progress?.. (1) Scrum Task Boards, Burndown Charts & Cumulative Flow • Allow to view Product Progress over time • Track against Release/Project Scope line • Allows Product/Service Owner & team to make course correction, if significant deviation from Ideal trend line
- 58. 58 And How to Track Product progress? ..(2) Release/Project Progress Detail Report • Allows to view progress at Epic level • Help to prioritize the sprint and release scope based on priority of each Epic and remaining work 0 20 40 60 80 100 120 140 160 Epic 10 Epic 9 Epic 8 Epic 7 Epic 6 Epic 5 Epic 4 Epic 3 Epic 2 Epic 1 Story Points Epic Completion Completed Size Estimated Size
- 59. Thank You
Editor's Notes
- #6: Without Lean Thinking, you really can’t be Agile! Lean Thinking provide a compass for good decision making Peeling the onion: Lean -> Thinking/Principles Agile -> Mindset/Values Scrum -> Process/Framework XP -> Engineering Practices
- #9: The Wrong Way to do Agile: Specifications The Wrong Way to do Agile: Planning How to: Improve Sprint Backlog Refinement/Grooming