CSM Certified Scrum Master Certification Cheat Sheet

I've been doing Scrum and other forms of agile development for 20 years, yet I never took a Scrum Alliance course until my consulting work required me to be obtain the CSM Certified Scrum Master certificate. And wow! It is an eye opener to understand how Scrum is truly intended to be applied, as opposed to the way organizations apply it only partly. 

Below are my notes from a fantastic Scrum Alliance course that will hopefully help anyone looking to get the certification, or simply understand the real Scrum, in depth.

---

AGILE VALUES

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation (documentation should be barely sufficient)
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

12 AGILE PRINCIPLES
From the Agile Manifesto: 

1. Customer Satisfaction - our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome Changing Requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Frequent Delivery - deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Collocated Team - business people and developers must work together daily throughout the project
5. Motivated Individuals - build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Visualize the org chart and flip it upside down. Now you have the value creators at the top, and the control people are in a support role. Instead of "Do this for me", servant leaders ask "how can i help?"
6. Face-to-face Conversation - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
7. Working Software - Working software is the primary measure of progress
8. Constant Pace - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This is to ensure no one burns out, and so that stakeholders can expect a predictable level of quality each sprint (it's hard to have both!)
9. Continuous Attention to technical excellence and good design enhances agility. The company should always be thinking about how to train staff and help them master skills. Where people are trusted and interested in their work, if you put them in challenging roles, they rise to the challenge! 
10. Simplicity - the art of maximizing the amount of work not done is essential.
11. Self-Organization - the best architectures, requirements, and designs emerge from self-organizing teams (in fact, anything that emerges from self-organizing teams will be the best version of that thing)
12. Regular Reflection - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

5 SCRUM VALUES

1. Commitment - everyone on the scrum team is helping everyone else on the team to get to the goal. Like a soccer team with a single ball, we all work together.
2. Courage - need to have the courage to have hard conversations, or say that you don't have the skills to do something
3. Focus - when you take on a task, you stick with it from start to finish. Only when you are done do you move on to the next task (monotasking).
4. Openness - open to share information, no information hoarders! 
5. Respect - everyone is equal, teams are flat, no hierarchy

THE 5 SCRUMS EVENTS 

Scrum Event 1: The Sprint
Sprints last 1-4 weeks. Long ago, the typical sprint lasted 4 weeks, but in the last 10 years it's become the norm to have 2-week sprints.

Who decides how long? The team. Sprints then always last the same amount of time. All work happens during sprints, including the 4 other scrum events below. No work happens "in between" sprints. 

There are no special sprints such as "testing" sprints or "hardening" sprints. Each sprint results in a Done, Usable and potentially releasable increment of valuable product.  

Scrum Event 2: Sprint Planning
Occurs once at the start of each sprint. Usually 2-4h meeting, 8h max.

Why Are We Sprinting? Negotiate the Sprint Goal

• Product Owner explains the sprint goal (that they came up with the previous week). If the sprint goal is way too big, the developers are obligated to NEGOTIATE the size of the sprint goal with the Product Owner.
• The Developers asks each other: who's taking vacation this sprint? Who's away? Then you know your capacity for the sprint and whether the goal is realistic given the capacity.
• NOTE: Scrum has evolved recently to be Goal-oriented. You always structure a sprint around a single valuable goal, not just lists of priority items. If an item is high-value (e.g. #2 item on the backlog) but doesn't relate to the sprint goal, then you don't take it into the sprint.

What Do We Need To Get Done This Sprint To Achieve The Goal?

• What known items do we need to work on to achieve the goal? The Product Owner and Developers select which items from the Product Backlog are needed to achieve the goal. 
• So, what is the Product Backlog?
  • a prioritized list of every possible thing we'd like to get done for the product
  • The Product Owner has prioritized the whole backlog by VALUE, using a value system that they choose (such as potential ROI of each item, or by cost of each item, or some ROI/cost combination)
  • The backlog is force-ranked: #1 priority, #2 priority , #3 priority, etc. Nothing should be of equal priority. The Product Owner spends time every day prioritizing the backlog.
• ​The items selected from the overall Product Backlog to achieve the goal become the Sprint Backlog. 

How Are We Going To Accomplish The Sprint Backlog Items to Get to the Goal?

• Start with the top of the spring backlog, and one-by-one break each item into tasks. 
• Only Developers gets to talk. Everyone chips in with what they think.

Do We Have the Velocity To Get All Of These Tasks Done?

• Velocity = proven amount of work that -this specific team- can get done in an average sprint. 
• If the velocity of the team is 3, then the team should not take on more than 3 this sprint.
• The Scrum master asks the Developers: ​"Our velocity is 3. Confirm that we will only take these 3? Can you look at these tasks one more time - if we do only these 3, can we achieve the entire sprint goal? If not, adapt the goal to make it achievable within a velocity of 3."
• The Scrum Master then further asks questions about things he heard during the meeting:
  • "I heard Jane brought up a task. That sounded important but we moved on. Do we need to go back and add that one?"
  • "Are we now all confident we can get this done in sprint? If we do these backlog items in the way we just documented - will we actually accomplish the sprint goal?"

Scrum Event 3: Daily Scrum 
Must happen daily, but only lasts a few min. 15min per day max (most of the time should be 5-10min). 

• Only 1 role is mandatory at the daily scrum: Developers! (Product Owner and Scrum Master are optional, Developers decide)
• Note that in Scrum, Developers are not just software engineers. Developers is a broad term that encompasses anyone on the team who is doing the work items: engineers, DBAs, BAs, testers, lawyers, etc. 
• A popular agenda for the daily scrum is to go roundtable and answer 3 questions: "What did I do yesterday? What do I plan to do today? What impediments do I have now?"  However the founders only meant this as a suggestion.  The true approach to daily scrum is for the Developers to adapt the agenda to what is most useful to them for advancing the work, not reporting status. 
• Scrum master can collect the list of impediments from the daily scrum and follow up on them, as they are responsible for ensuring that impediments are solved (note: they are not necessarily the ones directly solving them)
• You don't look at the Burndown chart during Scrum. In fact, Burndown Chart has not been part of scrum for over 10 years, and Burnup chart was never part of Scrum.

Moving Items to 'Done'

• The Definition of Done is a standards document that applies to all work. Not the same as acceptance criteria which can apply to a specific product backlog item.
• The Definition of Done should be based on 3 quality standards:
  • ​industry standards, if you have them
  • company standards, if you have them
  • team standards
• If a sprint backlog item passes the Definition of Done, then it gets added to the Increment (=the sum of all work done by the team)
• In practice, if Developers believe that an item is done, they -immediately- bring it to the Product Owner to show them and confirm it.

The Increment is the sum of all work done by the team. The work within the Increment is Done, Usable (working product), Releasable (should always be in a state where you'd be proud of it to be released).


Optional Meeting: PRODUCT BACKLOG REFINEMENT
Initiated by Product Owner. There can be 1 or more each sprint. Previously called "Backlog Grooming".

Although Product Backlog Refinement is not one of the 5 official scrum events, the Product Owner has the option during the sprint to schedule one or more product backlog refinement meetings with the team. Refinement meetings are the main way in which the Product Owner provides transparency to the team the whole product backlog. 

Each refinement meeting follows 4 steps:

1. The Product Owner identifies 1 large backlog item that needs more clarity and provides a detailed brain dump of everything they know about the item to the Developers, in the meeting.
2. The Developers ask questions about the item, and the Product Owner must answer every question.
3. Then Product Owner and Developers work together to turn the large item into many smaller items instead ("refinement").  
4. The Developers are given the opportunity to size/estimate the work resulting from refinement.​

What Makes a Good Product Backlog Item?

A good product backlog item is in the form of a story that answers 3 key questions: 

1. Who is this work item for? 
2. What do you want us to build?
3. Why is it valuable/useful?

This is why many teams use "user stories" for their product backlog items in the format "As a [persona type], I want [certain functionality] because [reason why it is important/valuable]. Scrum doesn't require teams to follow this rigid format however, as long as the product backlog item can explain in some way the answer to the above questions.

Scrum Event 4: Sprint Review
Occurs at the end of each sprint, 1-2 hours long, 4 hours max

The Scrum Team attends, as well as all stakeholders who wish to attend. Can include:

• demo to stakeholders (customer, other teams, internal management, etc.). In fact the Sprint Review used to be called the Sprint Demo, but it changed names since it is now more than just a demo!
• actionable feedback from stakeholders. Feedback may go to the product backlog and/or to the retrospective. Never promise a stakeholder in the meeting that you'll do something though, the Product Owner will decide what the next sprint goal is offline.
• The Product Owner gives update on progress towards the product goal (a projection, not a promise or deadline)
• The Product Owner could talk about value and/or budget 
• The Scrum Master and Developers could highlight organization-level impediments that couldn't be solved during the sprint (e.g. red tape, bad procedures, things that slow or block the whole company)

Scrum Event 5: Retrospective
Facilitated by the Scrum Master. 1-1.5 hours, 3 hours max.

What is the Retrospective? 
The Retrospective is a meeting where the team inspects everything that happened in the sprint, and then uses the learnings to adapt the team's processes, tech skills, team dynamics, or anything else about their way of working.

Scrum has 3 pillars of empiricism: inspection, adaptation, transparency. These are especially demonstrated in the retrospective. We can't expect to inspect anything if we don't have transparency, i.e. an act of trying to find mutual understanding about what happened in the last sprint.

What Is The Agenda of a Retrospective Meeting?
The Retrospective has 5 parts to its meeting. Here they are with suggested timing: 

1. Setting the stage - 5min ​​
2. Gather data - 10-20min
3. Generate Insights - 35min
4. Decide what to do - 35min - this is the most important part!
5. The Close (summary) - 5min

Who Facilitates the Meeting?
The Scrum Master facilitates the meeting. This means that they are not a participant during the meeting, or there is too big a risk that they won't be trusted. The Scrum Master can ask questions but not contribute their own ideas.

Planning the Retrospective
The Scrum Master should invest 1-2x as much time preparing for the meeting as the meeting is long. For example, if the Retrospective is 1.5 hours, plan to prepare for 1.5-3 hours.   

Games During the Retrospective
The Scrum Master facilitates the meeting and uses games during the session to engage the team and help include all team members' input.  There are >300 known activities that can be used during the Retrospective, and it's encouraged to try different a different one each time.

During "Gather data" phase of the Retrospective, it is good to spend time playing a "sticky note" game to get people to think about the sprint that has just passed in different ways. For example, you can play:

• Loved / Learned / Lacked / Longed For
• Start Doing / Stop / Do More / Do Less / Continue
• What went well / Not well / Change

The above games, team members each get a few minutes to silently write on sticky notes things that they would classify into each category and paste them into the category.  Teams then vote on 3 topics among the many posted to the board that they would like to discuss in depth during the Generate Insights phase.

During the "Generate Insights" phase of the meeting, a second game can be played. 

If the team is meeting virtually, consider the use of a tool to play the game such as: Mural, Miro, Retrium, Jam boards, Confluence, Zoom whiteboards, Teams whiteboards.

Decide What To Do
Once you reached the "Decide what to do" stage of the meeting, the team should select the most important impediment or opportunity that has come up so far in the meeting, and spend time developing and agreeing to a step-by-step plan the plan to act on it.

To decide what the most important topic is, you can play a game such "Thumb Voting" which only takes 1 minute. Once you have your topic, you can decide on the step-by-step plan using another game such as dividing the team in half, each sub-team has 12 minutes to develop a step-by-step plan, and then the teams compare each others' plans and decide on a final plan together.

The Retrospective is not over unless you have a concrete, agreed plan. The Scrum Master may need to extend the time of the meeting! 

Retrospective Champion
Each sprint, a team member is assigned to be the retrospective champion on a rotating basis. The champion ensures that the step-by-step plan is taken on in the next sprint and reports on progress regularly at scrum meetings. The champion doesn't own the plan, the team owns it, but the champion is responsible for reminding the team about it. 

THE 3 SCRUMS ROLES

There are only 3 roles in Scrum: the Product Owner, the Scrum Master, and the Developers. Below we list each role's responsibilities. Note that doesn't differentiate between a "responsibility" and an "accountability". 

Note also that there is no "Project Manager" in Scrum. A traditional Project Manager's responsibilities are divided up among the 3 roles. 

Development Team

• Estimate work
• Define the scope of the Sprint Backlog
• Create a plan for the Sprint Backlog
• Produce quality work (the key word is "produce")
• Produce the increment
• Adapt the plan each day (e.g. during daily scrum)
• Implement action items (from retro)
• Ensure quality using the definition of done
• Improve their own dev practices

NOTE: Developers are not just software developers, but anyone who is taking on sprint backlog items such as architects, testers, cyber security, lawyers, and so forth!

Product Owner

• product vision
• orders the Product Backlog
• maximizes the value of the product by coming up with long-term goals and chopping them up into smaller sprint goals
• decides when to release
• owns the budget (Product Owner is the liaison to the outside sponsor)
• the only person who is allowed to cancel the sprint, and this is only done in very rare circumstances if the sprint goal is no longer has any value

NOTE: there is only 1 authority on the whole team, which is the Product Owner's authority over the product. 

Scrum Master

• promote and support Scrum best practices
• responsible for removing impediments/barriers
• ensure psychological safety for the team, so that everyone can speak and share openly
• help those outside the Scrum team understand scrum and support the scrum team
• make sure sprint planning happens
• help the Product Owner by suggesting Product Backlog maintenance techniques
• help with Product Goal
• facilitate external stakeholder collaboration 
• coach the team

NOTE: the Scrum Master is the only person on the team that really cares about scrum. The Product Owner is super focused on the product, customer and stakeholders - they might not care about scrum. Developers care about their code and product, but they might not buy in to the process. The Scrum Master's job is to keep everyone focused on the principles of Scrum (and might be most successful using "covert scrum", i.e. subtly keeping the team on track without evangelizing "scrum" itself).

All roles:

• Are full-time working on the team and the product. Product Owner, Scrum Master, and Developers should not be working on another product at the same time!  
• Assist with impediments
• Hold each other accountable
• Can wear many hats. For example, a software engineer who doesn't have enough work is encouraged to fill the rest of their time testing the product.
• Continually experiment with new ideas (experiments = things we've never done as a team before, nice to have 1 experiment per sprint)

ROLE INTERACTIONS

• Scrum Master / Product Owner: the Scrum Master coaches the Product Owner on Product backlog maintenance techniques , i.e. coaches the Product Owner on how to be a Product Owner. In practice, Product Owners are often subject matter experts or business people who are not as familiar with Scrum techniques as the Scrum Master.
• Scrum Master / Developers: 
  • Developers need to remember to ask the Scrum Master for help with impediments and coaching. Of course, a good "bloodhound" Scrum Master is always listening, observing, and will see that they need help.
  • The Scrum Master helps Developers with self-organization.
• ​Product Owner / Developers
  • ​Product Owner / Developer communications - primarily clarifying product backlog items - makes up 83% or more of total communication among the team. 

SCRUM MASTER COACHING STYLES

The Scrum Master can use various styles when coaching team members. A popular framework is the 9 Stances of Scrum Master Coaching: ​

CRAFTING THE DEFINITION OF DONE

• When writing the Definition of Done, you need to be specific and try to avoid unwritten assumptions.
• Involve the whole team in the creation of the Definition of Done
• The Definition of Done applies to this team and is applicable to all work of this team. A different Scrum team will come up with their own Definition of Done.
• If you get a new team member, you are supposed to throw out the old Definition of Done (and other rules such as the Definition of Ready) and re-create the rules document with that new team member involved. That way the new team member truly has ownership in the Definition of Done, and has the context of having been there when it was written. In practice it will probably be about 95% the same as before.
• Aside from a new team member joining, the Definition of Done should be consistent and long-term. Don't change it each time you go into a new sprint.

SPECIAL TERMS IN SCRUM

• ​There are 3 artifacts:
  1. the product backlog (a representation of work in the future)
  2. the sprint backlog (a representation of work being done now) 
  3. the increment (a representation of work of the past)
• Scrum does NOT use certain words:
  • "assign" - no one assigns tasks (because everyone is equal)
  • requirements (use "product backlog item", "sprint backlog item")
  • calling people "human resources" is definitely not allowed
  • instead of "action item" resulting from the Retrospective, we call it a continual improvement item.  
• Scrum of scrums is meant to be a one-off meeting involving multiple Scrum teams who have dependencies. In the meeting, the teams get together and actively use the meeting to solve dependency related issues.  In practice, many organizations use the Scrum of scrums differently than is intended.

EQUALITY AND SELF-ORGANIZING TEAMS

• In Scrum, there's no RACI or communications plan. All communication is open. Because everyone is equal, a team member can go talk to the CEO if they think there's a problem.

• Self-organized Teams is no longer the ultimate maturity goal because it's understandable. Now the ultimate maturity goal of a scrum team is to be self-managed teams. Self-managed Teams would even include things like the team collectively deciding whether Developer A gets a raise, Developer B gets a promotion, etc. Today <1% are self-managed.