Scrum master


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Scrum master

  1. 1. Overview of Scrum3 roles3 artifacts4 ceremonies
  2. 2. Scrum
  3. 3. Scrum Overview● Take a prioritized backlog of features● Deliver potentially shippable incrementsof product every 1-4 weeks● Using 3 roles, 3 artifacts, and 4ceremonies● suggested 5-9 people per team○ scale via multiple scrum teams and scrum ofscrums
  4. 4. ● Owns the Product Backlog● Responsible for the business value of theproduct (ROI)● Client or client proxy● Usually a business person or domainexpert● Answers questions about Backlog items● Needs to learn how to value at thefeature level vs the product levelThe Product Owner
  5. 5. ● Developers, Testers, DBAs, UX, Ops - nolonger● Responsible for completing tasks in thebacklog● No I in team, succeed or fail as a group● Self-organizing● Cross-functionalTeam Member
  6. 6. ● There to facilitate the Scrum● Protects the team from distraction● Removes impediments● Coach/mentor/servant leader● Works for the teamScrum Master
  7. 7. ● Created/groomed by the Product Owner● Ordered by business value● Priority can be a function of value,technical scope, and technical necessityProduct Backlog
  8. 8. ● The tasks from the product backlog thatwill be completed this sprint● product backlog broken into manageablechunks● 50-80% capacitySprint Backlog
  9. 9. ● Shows progress through the sprint● A measure of success...(or defeat)Burndown Charts
  10. 10. ● Chickens and pigs● 3 Questions○ What did I do yesterday?○ What am I planning to do today?○ Do I have any impediments?● Discussions should be reserved tointerested people in separate meetingsTimeboxed to 15 minutesOccurs dailyDaily Scrum (Standup)
  11. 11. ● Planning Poker● 2 parts○ Estimate features, talk about why they areimportant (What and Why)○ Break down the features into small tasksand grab highest priority features until outof capacity (How)Each part timeboxed to 1 hour per week in sprint (ex. 2week sprint, part 1 - max 2 hours, part 2 - max 2 hours)Occurs first day of sprintSprint Planning
  12. 12. ● Show working software to stakeholders● Take questions and feedbackTimeboxed to 1 hour per week in sprint(ex. 2 week sprint max of 2 hours)Occurs last day of sprintSprint Review/Demo
  13. 13. ● Extremely important● Reflect on how the sprint went● Identify things that need to changeTimeboxed to 45 minutes per week in sprintOccurs last day of sprint after SprintDemo/ReviewSprint Retrospective
  14. 14. ● Keep to < 10% of capacity● Break down, analyze, estimate largestories● Either a meeting or team available tohelp product ownerOptional Sprint Task - ProductBacklog Refinement/Grooming
  15. 15. so what else did we learnThats All Scrum Is
  16. 16. ● The team must agree to a definition● Coded, unit tested, accepted by PO● + automated acceptance test in place● + documented● + ready for deploy to productionDefinition of Done
  17. 17. ● Up to the team to choose appropriatepractices● Start with 2-week sprints, adapt● Dont start or end sprints on Monday orFriday (theyre the most likely vacationdays)● Automated Acceptance and Unit Tests○ TDD and ATDD/BDD● Continuous IntegrationRecommended Practices
  18. 18. ● Pair Programming● Planning Poker● User Stories● Communities of PracticeRecommended Practices(Cont.)
  19. 19. ● Seed the product backlog● Build/grab a team● Make decisions on team rules, definitionof done, practices, technology stack● Setup version control, continuousintegration, continuous delivery,architectural skeletonSprint 0/Iteration 0/ProjectInception
  20. 20. ● The team decides them● Examples:○ Late to meeting: penalty○ Leaving the build broken: penalty○ No laptops or phones at meetings (exceptdriver)○ Definition of done○ Respect others - keep it short, 1 persontalking at a time, project your voice if onconference callTeam Rules
  21. 21. ● Relative○ Story points, T-shirt size, etc.○ Pros:■ Relative size stays the same, hour estimates perunit of size should improve■ Cant be mapped between teams○ Cons:■ Harder to learn how to do■ Cant be mapped between teamsRelative vs Hour Estimation
  22. 22. ● Hours:○ Pros:■ Easier to grasp○ Cons:■ Difference between senior and junior estimates■ May be taken as a commitment rather than anestimateRelative vs Hour Estimation
  23. 23. ● Other departments dont accept theScrum practices○ Anything can go on backlog, but nothing willbe worked immediately○ Non-agile contracts○ Dependencies with non-agile teams○ Annual reviews involve ranking peopleagainst one another instead of on teamsuccess or knowledge transferPain Points
  24. 24. ● Product Owner isnt full time with team● We sometimes let sprints go long● We dont do Daily scrum or sprintretrospective● We still throw code over a wall to testers● Team split between multiple projects● Not always bad ... but not ScrumScrum, But...
  25. 25. ● Incorrect metrics● Hiring● Furniture police● Hero team members● TrainingAll Dysfunction is Organizationalor Process Related
  26. 26. ● Co-located team - 0.6x● Large scale (Scrum of scrums) - 1.4xTime Bonus/Penalties
  27. 27. Number of Projects● 1● 2● 3● 4● 5● 6The Myth of MultitaskingEffective Hours per Day● 5-6● 4● 3● 2.5● 2● 1via Slack by Tom DeMarco
  28. 28. Overtime is a Lie● Overtime over a week will regress to themean○ 1st week youll get extra capacity○ After that at best youre getting 40 hours forthe 50 or 60 youre paying for● More defects● Employee morale declines
  29. 29. ● Succeeding with Agile by Mike Cohn● Agile Estimating and Planning by Mike Cohn● User Storied Applied by Mike Cohn● Agile Retrospectives by Esther Derby and Diana Larsen● Agile Coaching by Rachel Davies and Liz Sedley● Agile Software Development with Scrum by KenSchwaber and Mike Beedle●● References