Certified Scrum Master Training Notebook Sean Scott

1. Certified Scrum Master Training Notebook Sean Scott

2. Overview Scrum (n): An (intentionally incomplete) framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: Lightweight Simple to understand Extremely difficult to master It is a process framework. Not a fully defined process, technique, nor a methodology. The rules of Scrum bind together the events, roles, and artifacts governing the relationships and interaction between them. It is designed for Product Development Scrum Purpose: achieve the highest business value in the shortest amount of time Roles Artifacts Ceremonies Values Foundation • The hard requirements for Scrum are sparse, but fixed. If you aren’t doing ALL of the requirements, you aren’t doing Scrum.; you are doing: • Scrummish • Scrum-like • Scragile • Etc… Scrum Motto: Live Long and Prosper

3. Scrum Theory SCRUM • Scrum is founded on empirical process control theory, or empiricism. • Empiricism asserts that knowledge comes from experience and making decisions based on what is known. • Scrum employs an iterative, incremental approach to optimize predictability and control risk. • Scrum has NO defined processes. http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf#zoom=100

4. Projects 1 Chaos Complex 4 3 2 Simple Known Unknown Unclear Clear Technology or Technique Requirements

5. Agile Manifesto Agile Manifesto Values Individuals & Interactions over Process & Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to change over Following a Plan Potentially Shippable Product Increment Agile Inter-related and compatible Affect on the organization ScrumeXtreme Programming FDDDSDM Revolution Evolution

6. Roles There are only three roles, Product Owner, ScrumMaster, and Team Member. Scrum hos no concept of functional roles: developer, tester, DBA, BA, etc… Owns requirements and ROI Facilitator and Coordinator Accomplishes the project work A fourth role is eluded to: Stakeholder

7. Teams The Development Team is responsible for doing the work of the project. The team is small, self-organizing, egalitarian, cross-functional, and atomic. Their main goal is to produce a PSPI Small The Development Team should be between three and nine people. Fewer than three won’t give the team the agility they need and more than nine is too difficult to self-manage. Self-organizing The Development Team is self-organizing. There is no manager to dictate how the team should operate. They are given the goal of creating the most value as quickly as possible and it is up to them to figure out the best way to make it happen. It is common for a team to take three to six weeks to become cohesive and high-functioning. Egalitarian Everyone on the Development Team has the same role: Development Team member. Leaders may emerge, but they are considered leaders of equals and not managers. Cross-functional Everyone on the Development Team is responsible for all tasks. Unlike a Waterfall project, a database task won’t necessarily be done by the team’s database expert; a testing task won’t necessarily be done by the team’s QC expert. Every task is assigned to maximize overall velocity. Sometimes this means one particular tasks might be done by the non-expert. Main Team Goal: Produce a: Potentially Shippable Product Increment Self Organizing means the team determines their own internal rules. It does not mean the team is self selecting.

8. Product Owner The Product Owner should have a vested interest in the success of the project. They should have a complete understanding of what is needed; and should have the authority to commit the necessary resources it will take to complete the project. Writes requirements Decides what work is done Decides when work is “done” Determines ROI for each Sprint Single “wringable” neck* Understands the needs Authority to make decision Available as much as the team needs, but no more. *The Product Owner is solely responsible for the functionality of the application, and is the “single wringable neck” in regard to this. However, the team is responsible for delivering the product as described by the Product owner.

9. Scrum Master The Scrum Master is responsible for assuring the project progresses. They act as referee to make sure the Scrum rules are followed, they act as coach to help team members excel, an they act as body guard to protect the team from the rest of the world. Protects the team Coaches team members Available to facilitate meetings Assures team follows Scrum rules Not the team’s manager Uses influence to steer the team Creates a learning organization Serves the other team members Exemplifies Scrum Values Listens to all parties Uses Quiet Leadership skills

10. Analogies Dragon Boat A dragon boat has three types of team members, the rowers (the team,) the rudderman (the product owner,) and the drummer, (the scrum master.) The rudderman steers the boat. The drummer keeps the team working in harmony, and the team does the work of rowing. Jungle Safari A jungle safari typically assigns roles to the first two people: the first person cuts the path, the second person navigates, everyone else follows. In this example, the bushwhacker is the scrum master, the navigator is the product owner, and everyone else is the development team. NetFlix Scrum is like NetFlix disk delivery. You work on one disk at a time; and you can make any changes you want to the PBL. A sprint ends when you return your disk and a new sprint starts when a new disk arrives. Imagine if NetFlix was organized like a Waterfall project and required us to submit our disk list once per year; then wait 12 months, at which time all disks would be delivered at the same time. Any change to the list would cost us in additional fees and, potentially, delay the delivery of all of the disks. Road Trip Projects are like a road trip. We can make all the plans we want but, unless we have perfect information, things are going to come up that affect or invalidate our plans. Option A: Plan entire trip; follow plan exactly; accept where you end up. Option B: Plan first day; execute first day play. Plan second day, taking into account all information that can be gathered; execute second day plan. Continue planning and executing until you arrive.

11. Product Backlog Ordered by business value; not “prioritized.” Items can be dropped if they no longer make sense to do An ordered, dynamic list of features that might appear in the product Continuously changing as needs change or are discovered “Features” is not really defined. We know it when we see it. Fixed Scope Time Cost Per PMI Per Scrum Time Cost Scope Variable • Characteristics of a healthy backlog • Detailed Appropriately Emergent (progressively elaborated)Estimated Prioritized (ordered by business value) • FDD Definition of a Feature • Can be completed in 2 weeks or less by one person • Is user valued • Is user verifiable

12. Sprint Backlog Items from the product backlog that have been assigned to the current sprint. Often, PBIs are larger than can be done by one person within the sprint. PBIs are decomposed into as many SBIs as are necessary. Less than 1 day PBI #1 SBI #1.1 SBI #1.2 = + PBI #2 SBI #2.1 SBI #2.2 SBI #2.3 = + + PBI #3 SBI #3.1 SBI #3.2 SBI #3.3 = + + PBI #n SBI #n.1 = Sprint 1 User Interface Everything, across all layers, for one slice of functionality is done within the sprint. Business Logic Application Server Database

13. Tracking Tracking is required by Scrum, but how it is done is not defined. Some Examples of tracking mechanisms: Burn-down chart Task Board Earned Business Value Chart Burn Down Blue line represents a straight-line from start to finish Red line represents actual progress Task Board Tasks re moved from left to right as they are selected, worked, and completed Earned Business Value Chart Blue line represents business value Red line represents cumulative costs

14. Sprint (Iteration) The Sprint is a large time-box container which holds everything else PBIs can not be added to a sprint once it has begun. The only way to “remove” a PBI is to choose to fail the sprint. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Week 4 Week 2 Week 3 Week 1 2 hours / Week of sprint(Problem Discussion) 1 hour / week of sprint 45 min / week of sprint 2 hours / Week of sprint( Solution Discussion) *Attendance is not required, but there are responsibilities that need to be covered.

15. Daily Scrum One-way communication, not a discussion. No interruptions or questions • Risks • Issues • Blocks

16. User Stories User Stories are not prescribed by Scrum, but are a valid option. A user is a real person, not another system. 3 C’s Front of card Back of card As a <user role> I want to <get some result> so that <reason> We will validate this feature by <validation rules>

17. Sprint Planning using Stories

18. Planning (metrics) Velocity Velocity ─> Speed team completes tasks (Story Points completed per Sprint) Sprints Sprints needed = 1 + (Remaining Story Points / Historical Velocity of Team) This can be calculated before the project starts or any time during the project to calculate the time remaining. Financials $ per Sprint = the sum of each person’s Rate times Hours per sprint Project Budget (Estimate at Completion) = $ per Sprint * Total Sprints Estimate to Completion = $ per Sprint * Remaining Incomplete Sprints

19. Prioritization Return on Investment Order Project Backlog by ROI; putting the most valuable user stories first. Backlog MUST be prioritized with a simple prioritization, or ranking; not a value sort. There can be NO duplicate prioritizations. Consider allowing users to Buy-a-feature, by pledging money into an account that is used to pay for the feature. When enough money has been raised, the feature is moved to the top of the queue. MoSCoW method Must o Should Could o Wont QICK Chart QICK Chart used to prioritize User Stories

20. Kano Model Attractive Quality These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken. One-dimensional Quality These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken of and ones which companies compete for. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent more, then the customer will feel misled and it will lead to dissatisfaction. Must-be Quality These attributes are taken for granted when fulfilled but result in dissatisfaction when not fulfilled. An example of this would be package of milk that leaks. Customers are dissatisfied when the package leaks, but when it does not leak the result is not increased customer satisfaction. Since customers expect these attributes and view them as basic, it is unlikely that they are going to tell the company about them when asked about quality attributes. Indifferent Quality These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction. Reverse Quality These attributes refer to a high degree of achievement resulting in dissatisfaction and to the fact that not all customers are alike. For example, some customers prefer high-tech products, while others prefer the basic model of a product and will be dissatisfied if a product has too many extra features.

21. Bibliography

22. Tools and Techniques Group Thinking Six Thinking Hats Brainstorming Go-Round Group Mind Mapping Affinity Grouping Multi-voting Think and Listen (http://www.selba.org/EngTaster/Social/Facilitation/FacilitationTechniques.html) Requirements Gathering Interviews Surveys Observation Five W’s Metrics Burn Down Chart Non-convergent Velocity and Scope Creep Chart Earned Business Value Graph PBI Count Control Chart SBI per PBI Control Chart Velocity Control Chart Games Ball Point Game Group Sort Game Penny Flipping Game Three truths and a lie Project/Task Selection SWOT Analysis QICK Analysis