Download as PDF, PPTX
![EXERCISE
Create a 2-3 PBI For A Social Network
Special For Dog Owners
As a [user]
I would like to [what]
So that [why]](https://image.slidesharecdn.com/psday2-160907125947/85/Practical-Scrum-day-2-24-320.jpg)
![EXERCISE
Estimate The Following Based On Weight In
Kilograms [No Google Please!!!]
• Chihuahua
• Great Dane
• Staffordshire bull terrier
• Appalachian mountain dog
• Border Collie
• American Cocker spaniel](https://image.slidesharecdn.com/psday2-160907125947/85/Practical-Scrum-day-2-36-320.jpg)
More Related Content
Similar to Practical Scrum - day 2
Practical Scrum - day 2
- 1. PRACTICAL SCRUM Like us:www.facebook.com/PracticalAgile Visit: www.practical-agile.com Follow me: @Linkedin Tweet: @PracticalAgile1 CONSTANT HIGHER MORE LEARNING QUALITY FUN Day 2
- 2. EXERCISE Write 5 MultipleSelection Questions On Yesterday Material Reminder: Agile Scrum (roles, ceremonies) Transparency DoD Waste Lean Thinking
- 3. BEING AGILE ISOUR FAVORITE THING
- 4. What are wegoing to cover today? TABLE OF CONTENTS 5 21 35 56 60 87 90 What does it mean to be a product owner? How to write requirements? How to estimate stories Long term planning in agile What is the meaning of each ceremony in scrum? How do we scale up? Agile engineering Practices
- 5. PRODUCT OWNER (PO) •Defines the features of the product • Defines release dates and content • Responsible for ROI • Prioritizes feature according to value • Can change features and priority once every predefined interval • Decides what will be worked on in each iteration • Accepts or rejects results
- 6.
- 7.
- 9.
- 11.
- 13.
- 14. Traditionally throws content“over the fence”
- 15. The PO takesan active role throughout the development lifespan Traditionally throws content “over the fence” NO MORE! CONCEPT CHANGE
- 16. How? • Talk directlyand frequently with your customers • Talk directly and frequently with your development teams • Engage the development teams in creating value for your customers • Maintain your product’s quality and agility – do not let technical debt accumulate
- 17. Manage the productBacklog 1. Clear 2. Ranked 3. Optimize the value 4. Visible transparent 5. Ensure understanding
- 19.
- 20. Description Value EstimateAcc. test sprint Wiki link As a …I would like to… so that 1200 3 1 www….. As a …I would like to… so that 1100 5 Show successful login & Show failing login 1 As a …I would like to… so that 1000 3 1 As a …I would like to… so that 700 8 2 As a …I would like to… so that 10 8 2 ... …
- 21. As a {persona/user} I would like to {do something} so that {achieve something} In order to {achieve something} as a {persona/user} I would like to {do something} User Stories
- 22.
- 23. EXERCISE Define 3 UsersFor A Social Network Special For Dog Owners
- 24. EXERCISE Create a 2-3PBI For A Social Network Special For Dog Owners As a [user] I would like to [what] So that [why]
- 25. Product Backlog Refinement= Grooming The team and the PO together review the backlog in order to make it ready for the next 2-3 sprints How? Grooming = Clarifying, Estimating, and Splitting Recommended to allocate ~5% of the sprint time
- 26. Splitting User Story Differentscenarios Stubbingmocking external dependencies Splitting across the data model (e.g login only via username, no password) Splitting across operations (e.g. delete & create, no update) Splitting on results (e.g Success and failure scenarios) Splitting cross-cutting concerns (e.g Security) Splitting functional & non-functional requirements (e.g Scaling)
- 27.
- 28. The terms and conditionsto be met in order to accept a requirement as Done ACCEPTANCE CRITERIA
- 29. GIVEN a pre-condition WHENan action happens THEN an expected result occurs Helps the team visualize what will it look like when it gets Done
- 30. •GIVEN login dialog WHENuser enters username=“Mickey” AND password=“Mouse” THEN user succeeds to login
- 31. •GIVEN login dialog WHENuser enters username=“Mickey” AND password=“Mouse” THEN user succeeds to login •GIVEN login dialog WHEN user enters username=“Mickey” AND password=“TheMouse” THEN user fails to login
- 32. •GIVEN login dialog WHENuser enters username=“Mickey” AND password=“Mouse” THEN user succeeds to login •GIVEN login dialog WHEN user enters username=“Mickey” AND password=“TheMouse” THEN user fails to login •GIVEN login dialog AND login_type=“secure” WHEN username=“Mickey” AND password=“Wrong” WHEN submit WHEN submit THEN user is blocked
- 33. EXERCISE Write 2-3 AcceptanceCriteria For The Highest PBI Given…When…Then….
- 35.
- 36. EXERCISE Estimate The FollowingBased On Weight In Kilograms [No Google Please!!!] • Chihuahua • Great Dane • Staffordshire bull terrier • Appalachian mountain dog • Border Collie • American Cocker spaniel
- 37. “IT IS BETTERBE ROUGHLY RIGHT THAN PRECISELY WRONG” John Maynard Keynes
- 38.
- 39.
- 40. • We are: - Not good in measuring absolute values - Good in comparing things • We have the basic math skills (or a calculator) • High accuracy has a high toll • Estimates become commitments • Time is not persistent Why Relative?
- 41. Story Points: They reflectthe “bigness” of a user story How hard it is ? How risky it is ? How much of it there is ? 5 ? 3
- 42. 1. Each persongets a deck of cards (Fibonacci) 2. The item to be estimated is read to all 3. Attendants ask clarifications for the item 4. Each person selects a card and puts it on the table facing down 5. When everyone is done, cards are exposed 6. If the estimations do not match a short discussion is done: Highest and Lowest estimators speak first -> return to step 4 7. Handle next item Planning Poker:
- 43. EXERCISE Estimate The FollowingBased On Size Using Planning Poker • China • Luxembourg • Denmark • South Africa - 8 (Reference point) • Belize
- 44. • Those whodo the work estimate it • Emphasizes relative estimation • Estimates are within one order of magnitude • Modeled for open discussion – forces thinking • Reduces anchoring - Everyone's opinion is heard WHY USE PLANNING POKER?
- 45. One page spec GroupA 7 Pages spec Group B 173 hours 117 hours Specification Length
- 46. Group A added irrelevantdetails: •End user desktop apps •Usernames & passwords •Etc Group B 39 hours 20 hours Irrelevant Information
- 47. Requirements 1-4 Group A Requirements1-5 Group B 4 hours 4 hours Requirements 1-5 but told to estimate 1-4 only Group C 8 hours Extra Requirements
- 48. Group A Customer thinks500 customer has no technical knowledge Don’t let the customer influence you Group B 555 hours 456 hours Same as B customer thinks 50 Group C 99 hours Anchoring
- 49. WHY USE PLANNING POKER? IT ISQUICK! IT IS FUN!
- 50. Spain 3 China Toobig Luxembourg 0 Denmark 1 South Africa 8 Belize 1 Chihuahua 3 Great Dane 90 Staffordshire bull terrier. 17 Appalachian mountain dog. ??? Border Collie 34 American Cocker spaniel 13 The Results
- 51. Velocity = Speed+ Direction How many points can the team complete in one iteration Easy to measure Fixes estimation errors Easily reflects the project status Primary parameter in planning
- 52. SP 8 priority 5 priority 4 SP 8 priority3 Planning Iteration Planning As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration SP 5 priority 2 Planning SP 2 Iteration 1: SP Done = 5+8+2 = 15 velocity = 15
- 53. SP 8 priority 5 priority 4 SP 8 priority3 Planning Iteration Planning As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration SP 5 priority 2 Planning SP 2 Iteration 1: SP Done = 5+8+2 = 15 velocity = 15 priority 7 SP 5 priority 6 Planning As Elad, product owner, I would like to calculate team velocity so that I will be able to estimate how much work we are going to complete in two months SP 8 priority 5 Planning SP 2 Iteration 2: SP Done = 8+5 = 13 velocity = (15+13)/2 = 14
- 54. SP 5 priority 8 What willhappen if support is needed? SP 2 priority 7 Long Term Crisis: Planning Iteration 3: SP Done = 2+5 = 7 velocity = (15+13+7)/3 = 12~ SP Done: Iteration 4 = 5 Iteration 5 = 7 Iteration 6 = 6 Velocity = (13+7+5) = 8 Velocity = (7+5+7) = 6 Velocity = (5+7+6) = 6
- 55. Planning For Support: Alternatingteam each sprint Alternating person each sprint Limiting the hours per team Use velocity - Ignoring it completely
- 56.
- 57.
- 58. Calculating Release Time Giventhat: The items for the release are estimated The velocity is known (or predicted) We know the scope or deadline #Story points Time Velocity
- 59. Calculating Release Time Wecan estimate: How much content can we do until the deadline How many sprints it will take to complete the content # Sprints X Velocity = # Story Points # Story Points Velocity = # Sprints____________ #Story points Time Velocity
- 60.
- 61. Sprint Planning The firstmeeting of the sprint Length: 2-8 hours Participants: PO, Team, Scrum Master Preconditions: Product backlog should be in good shape Divided into two parts
- 62.
- 63. Sprint Planning -Part I Decide what the team takes to part II 1. PO Explains the top items from the backlog 2. Team decides what takes to part II in order to commit for sprint content 3. Team and PO selects the sprint goal
- 64. Sprint Planning -Part II Generate the sprint backlog & commit on the sprint’s content How? Splitting each of the stories into smaller tasks Estimating each task (maximum length 8 hours) Design decisions Verify that the goal is achievable Commit
- 65.
- 66. The sprint Backlog Belongsto the team Assists the team in tracking the sprint’s progress Maximum task length should not exceed 16h (2 days) for a 2 week sprint Updated throughout the sprint • Every team member can add, remove or change the sprint backlog • Status of tasks & remaining work is updated daily • Sprint content emerges
- 67. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 68. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 69. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 70. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 71. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 72. Burndown Chart A simplevisual way of tracking progress Used in different levels: Sprint Release Product Shows the amount of work left to reach target
- 73. Effortremaining 0 25 50 75 100 Sprint 1 2 34 5 6 7 8 Release Burndown Chart
- 74.
- 75. Every day, Sametime, Same time No longer than 15 minutes Stand up All the team must attend Only team members are allowed to speak Daily
- 76. Daily 3 Questions: 1. Whathave we accomplished since the last daily 2. What will we complete until the next daily 3. What are my/our impediments
- 77. Sprint Review Show &Tell Bazar Review
- 78. Close the sprint Participants: The team, PO, everyone (managers, customers..) Inspect & adapt, focus on feedback - this is NOT a Demo Focus on shard learning - not reporting Only Done Working Software allowed Avoid power point presentation Sprint Review
- 79.
- 80.
- 83. Sprint Retrospective ‘The greatestenemy of great is good enough’
- 84. Goal: Inspect andcreate plan for improvements Team time tune & adjust After sprint review - Before sprint planning Length: 1-2 hours Participates: Scrum Master and the team (others are optional) Generate AI (experiments) to execute the following sprint Sprint Retrospective Things to Stop doing Things to start doing Things to Keep doing
- 85. Retrospective Model Example Opening(2-5 minutes) Data collection (15-25 minutes) Generate insights (15-25 minutes) Decide what do do (15-25 minutes) Closing (2-5 minutes)
- 86. THE WRONG WAYTO DO RETROSPECTIVE
- 87. LeSS - LargeScaling Scrum
- 88. The basic assumptions (justlike scrum…) For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process control. There are no best practices. Only good practices within a specific context
- 91. Engineering Practices Pair programming Refactoring TDD ATDD Continuous integration
- 92. Pair Programing A techniqueused to: Increase quality level (code review is built in) Increase knowledge sharing Over time increase productivity
- 93. Refactoring Goal: Improve readabilitywhile preserving meaning Refactoring ≠ Redesign Does not fix bugs Done as a series of steps, each step does a little Refactoring is not a “standalone” task Most modern IDE’s have auto-refactoring tools
- 94. Test First /TDD - ATDD TDD – Test driven development: A Design technique Never write a line of code unless it fixes a failing test Red -> Green -> Refactor ATDD – Acceptance TDD: A Requirements management technique Requirements are written as functional tests Usually with tools such as Cucumber / SpecFlow For every failing functional test run the TDD cycle
- 95. Continuous Integration 1. Thesystem is always integrated (even multiple sites multiple components) 2. CI systems can and should be aggregated 3. Requires check ins as often as possible Usually done by a system that automatically: Generates a new build version Runs all unit tests Creates a deployable package Installs it to production equipment Runs all system tests Run LSP tests Publishes results •
- 96.
- 97. “THE VALUE OF ANIDEA LIES IN THE USING OF IT” Thomas Edison