1. CSE Senior Design II Scrum Review/Discussion Instructor: Mike O’Dell

2. 2 CSE 4316 (from Essential Scrum, Rubin) 2 Scrum Overview  Scrum Essentials  Roles  Activities  Artifacts

3. 2 CSE 4316 (from Essential Scrum, Rubin) 3 Scrum Activities Overview

4. 2 CSE 4316 (from Essential Scrum, Rubin) 4 The “Essence of Scrum” (according to O’Dell) Proactive management timely completionProduct Backlog Itemscustomer requirements “Proactive management of the Product Backlog toward timely completion of Product Backlog Items to address customer requirements for the product.”

5. 2 CSE 4316 (from Essential Scrum, Rubin) 5 The “Essence of Scrum”  “Customer requirements”  “Product Backlog”  “Product Backlog Items”  “Proactive management”  “Timely completion”

6. 2 6 The Product Backlog  A prioritized list of desired product functionality  A highly visible artifact at the heart of the Scrum framework and process  A tool for communicating with your Product Owner/Product Sponsor/end- user comunity  A critical input to the Sprint Planning process

7. 2 7 Product Backlog Items (PBIs)  Features, functions  Features, functions that have tangible value to the customer/end-user  Changes/enhancements  Changes/enhancements to an existing or previously implemented feature or function  Defects  Defects that need to be fixed  Technical improvements  Technical improvements to the product  Knowledge acquisition  Knowledge acquisition work associated with the product Product Owner deems valuable  Anything else the Product Owner deems valuable

8. 2 8 Product Backlog Items (PBIs) PBI TypeExample Feature/Function As a customer service representative I want to create tickets for customer issues so I can manage their support requests. Change/ Enhancement As a customer service representative I want my default ticket display to be by last name instead of ticket number so I can more easily find a specific customer’s service tickets. Defect Fix defect #256 in the defect tracking system so that special characters in a customer name do not make customer searches crash. Technical Improvement Move service ticket tracking data to the latest version of the Oracle DBMS. Knowledge Acquisition Create a prototype or proof of concept for the two proposed navigation models for the ticket tracking system and run tests to determine which is the most efficient. Product Owner Additional Prepare a mock-up of the proposed service ticket tracking GUI to be used for marketing research sessions with top-tier national customers. Some examples from Essential Scrum, Kenneth S. Rubin

9. 2 9 Product Backlog Characteristics  DEEP  Detailed appropriately:  Detailed appropriately: PBIs near the top (in priority) that we intend to work on soonest should be very detailed and small. Those near the bottom can remain as epics until the move up.  Emergent:  Emergent: It is never frozen. Instead, it is continuously updated based on new information.  Estimated:  Estimated: Each PBI has a size (effort) estimate. Those near the top should be most accurate and small enough to be completed in “a few days.”  Prioritized:  Prioritized: Especially important to have accurate prioritization for next few Sprints.

10. 2 10 Product Backlog Characteristics  DEEP: Detailed appropriately  DEEP: Detailed appropriately. Source: Essential Scrum, Kenneth S. Rubin

11. 2 11 Product Backlog Grooming three  Consists of three primary activities: 1.Creating and refining (adding details to) PBIs 2.Estimating PBIs 3.Prioritizing/reprioritizing PBIs DEEP  Employs DEEP ongoing, collaborative  Is an ongoing, collaborative effort, involving  Product Owner  Development team (everyone)  Internal and external stakeholders  Other subject matter experts, partners

12. 2 12 Product Backlog Grooming  Story Abstraction Hierarchy Source: Essential Scrum, Kenneth S. Rubin

13. 2 CSE 4316 13 Characteristics of a Good Requirement (PBI/User Story)  Independent.  Independent. One of the characteristics of Agile Methodologies such as Scrum is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

14. 2 CSE 4316 14 Characteristics of a Good Requirement (PBI/User Story)  Negotiable.  Negotiable. The only thing that is fixed and set in stone in an agile project is a Sprint backlog (and, even then, it can be broken). While the story is in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.

15. 2 CSE 4316 15 Characteristics of a Good Requirement (PBI/User Story)  Valuable.  Valuable. The focus here is to bring actual product-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software.

16. 2 CSE 4316 16 Characteristics of a Good Requirement (PBI/User Story)  Estimable.  Estimable. If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of an iteration. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the time, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

17. 2 CSE 4316 17 Characteristics of a Good Requirement (PBI/User Story)  Small.  Small. User story sizes should typically take only a few days to implement. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a Sprint backlog comes closer.

18. 2 CSE 4316 18 Characteristics of a Good Requirement (PBI/User Story)  Testable.  Testable. Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimable" above), the story should not be considered a good candidate to be part of a Sprint Backlog.

19. 2 CSE 4316 19 Characteristics of a Good Requirement (PBI/User Story) I.N.V.E.S.T.

20. 2 20 Estimation, Capacity, Velocity  Estimation  Estimation is the process of determining the effort required to complete (100% DONE!) each PBI on the Product Backlog  Capacity  Capacity is the effort available from the team to complete PBIs during the Sprint  Velocity  Velocity is the amount of work completed during a Sprint

21. 2 21 Estimation  Estimation is required for the entire Product Backlog (Release Planning) and for each Sprint (Sprint Planning)  Items higher in priority, or required earlier, need most accurate estimates (and smaller PBIs)  Items lower in priority/later require less accuracy  Must be done at the beginning of the Project then refined at the beginning of each Sprint whole team, using a common baseline  Must be done by the whole team, using a common baseline  Use an approach that works best for your team, product

22. 2 22 Estimation - When Source: Essential Scrum, Kenneth S. Rubin

23. 2 23 Estimation - How Source: Essential Scrum, Kenneth S. Rubin  Critical Rules and Concepts: 1.Estimate AS A TEAM 2.Estimates are not commitments 3.Focus on accuracy, not precision 4.Use relative instead of absolute sizes

24. 2 24 Estimation - How Source: Essential Scrum, Kenneth S. Rubin  Use the approach that works best for your team Relative sizes or adjective calibration Buckets or Bins Estimation Poker Betting Analogy

25. 2 25 Capacity  Capacity is used to determine what can (will) get done during each Sprint.  Team capacity for the Sprint >= the sum of estimated size of PBIs to be completed in the Sprint  Use the same units/metrics/sizings as for estimation  Consider actual effort available for work on PBIs Other Sprint Activities Other Non-Sprint Commitments Personal Time Sprint Buffer Capacity for work on PBIs during this Sprint Total work capacity during Sprint

26. 2 26 Velocity  Adds the size of all PBIs completed during a Sprint  Only count PBIs that are complete (100% DONE)  Measures output, not effort, outcome or benefit  Why measure velocity?  Scrum Planning: (estimated size of release) ÷ (measured velocity) = (number of Sprints required to complete release)  Sprint Planning: (velocity per Sprint) >= (size estimate for PBIs in Sprint  Metric: evaluate the team’s performance vs. processes/procedures and determine ways to optimize performance

27. 2 27 Velocity Source: Essential Scrum, Kenneth S. Rubin

28. 2 28 Velocity Source: Essential Scrum, Kenneth S. Rubin Product Backlog Item “Story Points”Sprint Review Results 22Accepted 1 31Accepted 54 83Rejected 93Accepted Sprint Velocity10 1 100% Done

29. 2 29 Velocity Source: Essential Scrum, Kenneth S. Rubin

30. 2 30 Source: Essential Scrum, Kenneth S. Rubin Estimated Size, Velocity, Duration (or capacity)