My SCRUM Guide

This is a short guide to the SCRUM Framework. If you are just beginning to learn about SCRUM, don't read this - the official SCRUM guide explains it better - and learning from an official scrum.org trainer is even better! I wrote this guide to help me study for the SCRUM master certification.

SCRUM is a deceptively simple framework within which people can deliver valuable solutions to complex problems:

Deceptively simple: Most people are tempted to tweak SCRUM, usually making changes to make it more complicated (the bigger the organisation, the more likely the urge to "customize") or more similar to existing habits. SCRUM leaves a lot of room for exactly how work is accomplished (Pair program if you want, co-locate or distribute geographically), but the ground rules work best when left as-is. Particularly deceptive is the fact that if you leave out one part, other parts might not work as expected.
Complex Problems: For simple or well-understood problems, where no surprises will occur, SCRUM might be overkill. Just make sure you really want to bet the farm on the "no surprises" part.
Valuable Solutions: SCRUM is really good at making people focus on value. Because you are not planning into the distant hazy future, everything you do must have a clear relation to a concrete benefit for the customer. Don't design for complications that might arise later, just get it working now! This is a balance which must be kept - the "simple" in "the simplest thing that can possibly work" doesn't mean "the fewest lines of code", it means conceptually simple. Multiple components each with a clearly defined responsibility can be conceptually simpler than one component that does everything.

Foundation

SCRUM is not a methodology. It does not mandate specific processes or techniques, but provides a framework in which processes and techniques can be employed (e.g. automated testing and QA, pair programming, etc.). The focus is on letting a motivated team with the necessary skills decide themselves how to achieve goals.

Empiricism

SCRUM is based on "empirical process control", or Empiricism- the idea that in a complex world, best results are achieved through Transparency, Inspection, and Adaptation. When it is not possible to decide in advance how to best accomplish goals, experiments are performed, and the process evolves with experience. SCRUM provides the process through which these experiments and the resulting adaptations can be structured and maximise the likelihood that process improvements are regularly identified and implemented.

Cone of Uncertainty

The Cone of Uncertainty illustrates the fact that the less you know, the harder it is to plan. If a decision can wait until uncertainty has decreased, the risk of making the wrong decision decreases. Given enough time, many decisions will make themselves.

Values

The values of SCRUM are:

Focus: Provide value right now. Don't spend the first 6 months setting up, designing, and preparing for future features. Implement a simple feature, end-to-end, which the product owner can use as inspiration for the next-most important simple feature. This is particularly important in sprint 1: Do the absolute minimum which will allow you to deliver immediately.
Courage: Empirical process control is based on experimentation. Instead of spending a lot of time trying to get it right the first time, just try whatever seems most likely to work, and if it doesn't, inspect and adapt. When problems are identified, it is essential to have the courage to speak up, and to do what's necessary to address them.
Commitment: The team commits to a sprint goal, and the product owner and scrum master commit to shielding the team from outside interference.
Respect: Everybody in the SCRUM team respect the other team members and trust them to be skilled, motivated, and independent. This starts with the product owner and the SCRUM master trusting the team to self-organise when deciding who does what.
Openness: When something is not working, or when things go wrong, it is important to be open about exactly what went wrong. Team members must have the courage to be open about problems, and trust other team members to have done their best.

The values help build trust between all involved, which produces a positive feedback loop where trust reinforces the values.

Framework

The SCRUM Framework consists of roles, rules, events and artifacts.

Roles

SCRUM Master (SM)

When teams start using SCRUM, they often think "SCRUM Master" is just a new and slight variation on the usual "Project Manager" role. This is unfortunate, because the SCRUM Master is not a Manager. S/he is an enabler who:

Helps the team self-organize
Leads and coaches in the organization
Plans SCRUM implementations
Helps people understand and enact SCRUM
Removes impediments for the SCRUM Team
Increases artifact transparency (learning, convincing, change)

Over time, and with continuous improvements to the process, the SCRUM Master ensures that the improvements do not conflict with SCRUM principles.

Product Owner (PO)

The product owner provides direction and guidance, and ultimately controls the direction in which the product is heading. This is a vital role - and often the hardest for organizations to put in place. The PO should be:

Product Market Expert: From a business perspective, intimate knowledge is required. Sometimes, the PO might have to clarify details (fair enough to want to sync with the people whose problems are being solved...), but generally, when a developer needs clarification for a task, the PO should be the obvious destination.
Product Value Maximizer: With limited resources, deciding what is the next "most valuable thing" to do is crucial. The PO must have a clear vision of where s/he wants to go, and make hard choices accordingly. This means deciding which minimal set of "small steps" will sum up to a "large step" in the right direction.
Facilitator of Stakeholder Involvement: There are two sides to stakeholder involvement - making sure everybody gets a say, and shielding the development team from noise. All requests and communication should be sync'ed with the PO, so s/he can make sure the focus stays on maximising value.

The team accepts no requests which do not come from the PO. This ensures that priorities among all stakeholders, not just the most vocal ones, are aligned, and the team can focus on what is truly the current highest priority.

Development Team

The developer team has 3 - 9 members (SM and PO do not count as members of the dev team). The SM and PO can also be developers, but this is not ideal, since conflicts of interest might occur. The team should be:

Self-organizing: The team decides internally how to achieve goals, including who does what. It is important for the Scrum Master and the Product Owner to be enablers and facilitators - which does not include having opinions about who should be assigned which task.
Cross-functional: The team possesses all skills required (Programmers, Architects, Business Analysts, Testers, Integrators, Support, Operators) to deliver the increment - minimize the number of team-external resources that can hinder progress.
One Single Unit: There are no "sub-teams", and the only role recognized is "developer". Anybody can participate in e.g. analysis and testing, which are typically areas where the volume of work varies depending on where the project is in the release cycle.
Constantly Improving: The team should always be looking to optimize creativity, productivity, and flexibility. The Retrospective is a regular opportunity to reflect, but the team is free to address impediments spontaneously.

Teams typically go through some steps before achieving a state of increased performance. Changing membership typically reduces cohesion, affecting performance and productivity in the short term.

Whether a team is doing SCRUM or not, the concrete work that needs to be done consists of the same kinds of activities. The basic "things that need doing" are performed by similar roles internally in the development team:

Developer ("Coder"): Perform the "real work", whether that is desigining software, writing code, laying bricks…
Business Analyst ("BA"): Support the PO in specifying exactly what needs to be done.
Project Manager ("PM"): Coordinate with other teams, interact with corporate entities, request and track required resources (component management, rights management, etc.). This is no longer a lead role, but external communication and coordination is still required.
Tester: Testing must be integrated in the team, as part of the daily work. Testing is not something that happens separately from development - if it's not tested, it does not work!
Specialist: Whenever special skills are frequently required, the Database Administrator, Software Integrator, Configuration Manager, Networking, Security, etc. should be part of the team.

Rules

Timeout

Time is of the essence- in order to reduce waste and maintain focus on the sprint goal, it is vital that every team member understands why they do what they do. At any point in any event, discussion or meeting, if somebody feels like their time could be better spent otherwise, they raise their hand. Whenever you see somebody with their hand raised, stop what you are doing, and raise your own hand. This should not be taken personally by the speaker, but simply serves as a reality check - is the current activity relevant for all those present?

Events

SCRUM Meetings are time-boxed, which mean they have a maximum duration. There is no minimum duration - if the meeting is done before the time-box expires, that's great, back to work! If topics in a meeting exceed the allotted time, take them offline, to allow the meeting to progress. Alternatively, if issues are identified or clarification is required, which require action or investigation before the meeting can progress, abort the meeting and reschedule.

External Stakeholders only participate in the sprint review - the PO represents them in other relevant meetings. Any member of the SCRUM team can interact freely with stakeholders otherwise.

Additional meetings are fine if they facilitate achieving the sprint goal. Make sure to listen when people say they have "too many meetings" in the retrospective - all meetings should be obviously useful to all participants!

Reduce the number of participants in meetings to the absolute minimum - there is nothing less motivating than being caught in a meeting where your only contribution is physical presence!

These are the only events/meetings required in SCRUM.
Meeting	Frequency	Purpose	Duration	Participants	Inputs	Outputs
Planning	Beginning of each sprint	Plan the next Sprint	Max 8 hours (but typically 1-2 hours)	The SCRUM Team	Current Increment Product Backlog Capacity Velocity	Sprint Goal Sprint Backlog Concrete plan for how to achieve the sprint goal
Daily SCRUM	Every day at the same time in the same place	Track progress towards sprint goal	Max 15 Minutes (typically 1 minute / participant)	Active: Developer Team Passive: Anybody else	Per participant: What did I do since the last daily? What will I do until the next daily? Is anything keeping me from progressing towards the Sprint Goal? These are guideline questions, not a prescription.	Impediments that must be addressed
Review	End of each sprint	Demo of what was implemented in the last sprint Get feedback from stakeholders Determine the focus of the next sprint	Max 4 hours (typically 1 hour)	SCRUM Team Stakeholders	All work accomplished up to and including the current Increment	Probable content of the next sprint
Retrospective	End of each sprint	Identify action points to increase efficiency/productivity	Max 3 hours (typically ½-1 Hour)	The SCRUM Team	All team members should prepare a list of things that went well and things that aren't going so well	Pain points that must be addressed (SM in lead)

Sprint Planning

The PO presents the contents of the next sprint. All stories must meet the definition of ready, particularly, they must be specified to a degree where any developer can grab them and start implementing, without needing to ask questions. Also, the stories must be estimated, so the team can confidently commit to finish the sprint backlog by the end of the sprint.

Daily (SCRUM)

Each developer team member briefly reports what was done since the previous daily, what will be worked on until the next daily, and which problems might hinder progress. Activities that have nothing to do with the current sprint are not relevant - this is not a status report to the team lead, so no justification is required. Focus on progress and problems. If there is nothing to say, shut up!

Every member of the team can raise their hand if they have the impression the daily is drifting off topic. If somebody raises their hand while you are speaking, that is valuable feedback - somebody does not understand why what you are saying is relevant to the current sprint goal. Either clarify, or cut it short.

Review (Demo)

This is where the team proudly presents what they have achieved in the current sprint. The focus should be on live demos - working software, not slides or status updates in tools.

Stakeholders are welcome, and the goal of the next sprint is an obvious point of discussion after seeing what was done in the current sprint.

Retrospective

The entire SCRUM team discusses what went well and what did not work so well. There are many different approaches to retrospectives, and changing the approach often can help keep people's attention. If people don't actively participate, or even suggest cancelling the retrospective, this is a warning sign - lethargy is often the result of too many retrospectives with the same issues being raised and nothing changing.

If there are no big problems to address, that's great, but that just means you can focus on solving smaller issues. Something which is a small, easily fixable problem today could become a big problem if left unattended.

Artifacts

Product Backlog

The Product Backlog is a sorted list of known requirements of the product. Nothing gets done unless it is represented in the backlog. The product backlog does not have to be complete, and the items can be at any level of detail. The PO owns the product backlog and decides on the order of items in it.

Sprint Backlog

During the sprint planning, the team decides which items from the product backlog will be included in the backlog for the next sprint. These items must be ready for inclusion, in particular, since the team commits to finishing these items in the sprint, the item must be understood well enough for the team to give a reliable estimate.

Backlog Item

Often correspond to Stories, Use Cases, Epics, Features, etc. in other methods. An item can be at any level of maturity to be in the product backlog, but must meet the definition of ready to be accepted into a sprint backlog. An item in a sprint is only considered done when it meets the definition of done.

Definition of Done

Since SCRUM puts the focus on delivering value, it is important to only consider an item done when real value has been provided. This means all tasks related to the feature must be finished: Testing, refactoring, integration into the main codebase, quality assurance checks, deployment to an environment representative of production. The definition of what this means must be agreed on by people with very different perspectives: All members of the SCRUM team must agree. The PO must make sure that the definition is acceptable to external stakeholders.

Definition of Ready

What does it mean for an item in the product backlog to be ready for inclusion into a sprint backlog? It is important to agree on what will be accomplished when the item is complete. Crucial is that the development team understand the item well enough to provide an estimate of how long it will take.