SCRUM Cheat Sheet by vini.vivero

Scrum is a lightw­­eight framework that helps people, teams and organi­­za­tions to generate value through adaptive solutions for complex problems

1. Indivi­­duals and intera­­ctions over processes and tools.
2. Working Software over compre­­he­nsive docume­­nt­ation
3. Customer collab­­or­ation over contract negoti­ation.
4. Responding to change over following a plan.
While there are value in the items on the right, we value more the items on the left.

2. Inspection

Is a concrete stepping stone toward the Product Goal.

 Each sprint should deliver an increment. A potent­ially releasable increment is created each sprint.
 Multiple increments may be created within a sprint.
Increment may be delivered to stakeh­olders prior to the end of the Sprint.
 Sprint Review should never be a gate to releasing value or a bottle neck. Showing or releasing an increment to the stake holders should no wait till the sprint review.
 Increments are an additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
 In order to provide value, the Increment must be usable.

The Definition of Done is a formal descri­ption of the state of the Increment when it meets the quality measures required for the product.

 It creates transp­arency, so everyone knows what needs completing and to what standards.
 If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.
 Instead, it returns to the Product Backlog for future consid­era­tion.

 If it is not an organi­zat­ional standard, the Scrum Team must create a Definition of Done approp­riate for the product.
 The scrum team can add standards.
 The Developers are required to conform to the Definition of Done.
 If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

 Once the developers meet the Definition of Done of a product backlog item, and increment is born.
 Once a Product Backlog Item meets the DoD is ready to present to the stakeh­olders and be considered for releasing to the users.

It is a list of work that need to be completed within the sprint.

Developers are always accoun­table for creating a plan for the sprint.
The Sprint Backlog is a plan by and for the develo­pers.
It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal

The Sprint Goal (why)
The set of Product Backlog items selected for the Sprint (what)
Actionable plan for delivering the Increment (how).

The Sprint Goal is the single objective for the Sprint.
Although the Sprint Goal is a commitment by the Develo­pers.
The sprint goal should be flexible enough in terms of the exact work that is needed to achieve.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog.
As the Developers work during the Sprint, they keep the Sprint Goal in mind.
If the work turns out to be different than they expected, they collab­orate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

The sprint Backlog is initially created during sprint planning session, developers are accoun­table of the amount work they can deliver.
The developers can modify the sprint backlog through out the sprint. And the sprint backlog emerges during the sprint.
This emergence occurs as the scrum team works through the plan and learns more about the work needed to achieve the sprint goal.
As more work is required, the developers add it to the sprint backlog.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Emergent: Means that you add to it and change it over time as you inspect and adapt
Ordered: Is ordered by priorities and/or depend­encies.
Single Source: Product Backlog is the single source of work undertaken by the scrum team

Developing and explicitly commun­icating the product goal.
Creating and explicitly commun­icating product backlog items.
Ordering product backlog items.
Ensuring that the product backlog is transp­arent, visible, and unders­tood.

Anyone can add details to a BLI with the Product Owner´s discre­tion.
Multiple teams can work together on the same product, but a single product backlog is used to describe the upcoming work on the product.

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
{{fa- circle­}}The scrum team should use this goal to plan the work to achieve this goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeh­olders, well-d­efined users, or customers. A product could be a service, a physical product, or something more abstract.

Scrum teams are cross-­fun­cti­onal.
Developers must be empowered and respected, they should be self-m­anaged. They are structured and empowered to manage their own work.
Developers are trusted to manage themselves to complete the work in the sprint backlog and holds themselves accoun­table for the success of the sprint.
Developers are also accoun­table to internally decide who does what, when and how.
It is up to the developers as a self-m­anaged team to create a plan to complete the sprint goal (Sprint backlog).
If some of the developers are struggling with assigned work they need to help each other.
Developers should meet the Definition of Done for each task.
They should adapt their plan each day toward the sprint goal.
Developers should meet every day at daily scrum.
There are no sub-teams or hierar­chies, developers are a cohesive unit of profes­sio­nals.

Creating a plan for the sprint, the sprint backlog
Instilling quality by adhering to a definition of done
Adapting their plan each day toward the sprint goal
Holding each other accoun­table as profes­sio­nals.

The purpose of the daily scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
Daily Scrums improve commun­ica­tions, identify impedi­ments, promote quick decisi­on-­making, and conseq­uently eliminate the need for other meetings.
During Daily Scrum you can answer this questions:
1- What I did Yesterday.
2- What I plan to do today.
3- What is Blocking me.

It is held at the same time and place every working day of the sprint.
Is is a 15 minutes event for the Developers of the Scrum Team.
Developers are the only ones are required.
Developers can select whatever structure and techniques they want, but they must focus on progress toward the sprint goal and produce and actionable plan for the next day of work.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discus­sions about adapting or re-pla­nning the rest of the Sprint’s work.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collab­orative work of the entire Scrum Team.

The Product Backlog must be refined.
The whole Scrum Team is required, that means that more than just the scrum team can be involved.
The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.
Every partic­ipant must know what the Sprint Goal is.
Sprint Planning results in a plan for the sprint, The Sprint Backlog

The Scrum Team can decide the sprint goal by consid­ering the following three topics during the planning session:
1- Why is this Sprint valuable?
2- What can be Done this Sprint?
3- How will the chosen work get done?

The Product Owner proposes how the product could increase its value and utility in the current Sprint.
Then, the whole Scrum Team then collab­orates to define a Sprint Goal that commun­icates why the Sprint is valuable.
The Sprint Goal must be finalized prior to the end of Sprint Planning.

Developers select items from the Product Backlog to include in the current Sprint.
The Scrum Team may refine these items during this process, which increases unders­tanding and confidence.
Selecting how much can be completed within a Sprint may be challe­nging. However, the more the Developers know about their past perfor­mance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

For each selected Product Backlog item, Developers plan the work necessary to create an Increment that meets the Definition of Done.
Developers decomposed Product Backlog items into smaller work items of one day or less.
No one else tells the Developers how to turn Product Backlog items into Increments of value.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adapta­tions. The Scrum Team presents the results of their work to key stakeh­olders and progress toward the Product Goal is discussed.

Scrum Team and stakeh­olders review what was accomp­lished in the Sprint and what has changed in their enviro­nment.
 Based on this inform­ation, attendees collab­orate on what to do next.
 The Product Backlog may also be adjusted to meet new opport­uni­ties.
 The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presen­tation.

Should be keeping on top of changes in the market place and be ready to make decisions on how to maximize the value of the product.

Inspect the outcome of the Sprint and determine future adapta­tions
To transp­arently inform about work which has been done (including adding work) and work has not been done (including work removed).
Take advantage to receive feedback from the stakeh­olders and adapt.

 The Product Owner is a value maximizer.
 Is accoun­table for effective product backlog management.
 Decides work tasks priority, is accoun­table for ordering product backlog items
 Must understand the market and the product to understand what makes a valuable product.
Accoun­table to clearly commun­icate the Product Backlog Items.
 Accoun­table to ensure the Product Backlog is Transp­arent, visible and understood.
 Represents the needs of many stake holders in the product backlog.
 The Product Owner Vision is called "The Product Goal"

Is the Product Owner Vision, is a long term objective for the Scrum Team

The Scrum master is a servant leader, who serves the scrum team, the product owner and the organi­zation.
The Scrum master is accoun­table for stabli­shing scrum as defined in the scrum guide. They do this by helping everyone to understand scrum theory and practice, both within the scrum team and the organi­zation.
The scrum master is accoun­table for the scrum team effect­ive­ness. They do this by enabling the scrum team to improve its practices within the scrum framework.

Coaching team members to work together on the sprint goal through self management and cross-­fun­cti­ona­lity.
Helping the scrum team focus on creating high-value increments that meet the definition of done.
Encourage the scrum team to raise problems, discover any depend­encies or impedi­ments and help to remove them finding solutions so the team can progress.
Ensuring all scrum events happen are positive, productive and kept within the time box.
Scrum masters coach the team on how to do scrum properly.

Helping find techniques for effective product goal definition and product backlog manage­ment.
How to decompose BLI to be ready for the sprint.
Helping the scrum team to understand the need for clear and concise product backlog items.
Helping establish empirical product planning for a complex enviro­nment.
Facili­tating stakeh­older collab­oration as requested or needed
Promote the inspection and adaption opport­unities for empirical product planning.

Leading, training, and coaching the organi­zation in its scrum adoption.
Planning and advising scrum implem­ent­ation within the organi­zation.
Helping employees and stakeh­olders understand and enact an empirical approach for complex work.
Removing barriers between stakeh­olders and scrum team

The purpose of the Sprint Retros­pective is to plan ways to increase quality and effect­ive­ness.
The Scrum Team inspects how the last Sprint went with regards to:
indivi­duals
Intera­ctions
Processes
Tools
Definition of Done. {{nl}
 This event is a good chance to add to the wealth and improve the definition of done.

what went well during the Sprint
what problems it encoun­tered
how those problems were (or were not) solved. Key Points

focus on How you are working as a team
The Scrum Team identifies the most helpful changes to improve its effect­ive­ness.
Impactful improv­ements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retros­pective concludes the Sprint.