Show Menu

This cheat sheet has the scrum essential topics

Scrum Essentials

Scrum Definition
Scrum is a lightw­­eight framework that helps people, teams and organi­­za­tions to generate value through adaptive solutions for complex problems
Agile Manifesto
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.

Pillars of Empiri­cism

1. Transp­­arency
2. Inspection
3. Adaptation

Scrum Values

1. Commitment 2. Focus 3. Openness 4. Respect 5. Courage

The Increm­ent

Is a concrete stepping stone toward the Product Goal.
Key Points
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 commitment for the increment is: The Definition od Done (DoD)
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.
DoD creates transp­arency by providing everyone a shared unders­tanding of what work was completed as part of the Increment.

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 the Definition of Done for an increment is part of the standards of the organi­zation, all Scrum Teams must follow it as a minimum.
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.
Key Points
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.

Scrum Artifa­cts

Scrum’s artifacts represent work or value. They are designed to maximize transp­arency of key inform­ation. Thus, everyone inspecting them has the same basis for adapta­tion.

Each artifact contains a commitment to ensure it provides inform­ation that enhances transp­arency and focus against which progress can be measured:

1. For the Product Backlog it is the Product Goal.
2. For the Sprint Backlog it is the Sprint Goal.
3. For the Increment it is the Definition of Done.

Scrum Princi­ples

1. Satisfy Customers Through Early & Continuous Delivery.
7. Working software is the primary measure of progress.
2. Welcome Changing Requir­­ements Even Late in the Project.
8. Agile Processes to support a consistent develo­­pment pace.
3. Frequent Delivery of working software.
9. Attention to technical detail and design enhances agility.
4. Collab­­or­ation between the business stakeh­­olders and developers throughout the project.
10. Simplicity (the art of maximizing the amount of work not done) is essential
5. Support, trust and motivate the people involved.
11. Self-o­­rg­a­n­izing teams encourage great archit­­ec­tures requir­­ements and designs.
6. Enable face-t­­o-face intera­­ct­ions.
12. Regular reflec­­tions on how to become more effective.

The Sprint Backlog

It is a list of work that need to be completed within the sprint.
The Developers owns the Sprint Backlog
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 Backlog is composed of:
The Sprint Goal (why)
The set of Product Backlog items selected for the Sprint (what)
Actionable plan for delivering the Increment (how).
The commitment for the sprint backlog is: Sprint Goal
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.
Key Points
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

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.
Product Backlog is:
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
The product owner owns the product backlog
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.
Key points
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.
Commitment to the product Goal
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.
Product Definition
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 Roles and Respon­sib­ilities

Accoun­table For:
Product Owner
The product owner(PO) is accoun­­table for maximizing the value of the product resulting from the work of the scrum team.
Developers (Devel­­opers & Testers)
Developers are the people in the scrum team accoun­­table for create any aspect of a usable increment each sprint. (Devel­­opers and Testers)
Scrum Master
The scrum master is accoun­­table for the scrum team effect­­iv­e­ness. They do this by enabling the scrum team to improve its practices within the scrum framework.

Deve­lopers (Devel­opers & Testers)

Key Points
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.
Developers are always accoun­table for:
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.

Scrum Events

Daily Standup
Sprint Planning
Sprint Review
Sprint Retros­pective

Daily Standup

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.
Key Points
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

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.
Key Points
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
Deciding the Sprint Goal
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?
1- Why is this Sprint valuable?
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.
2- What can be Done this Sprint?
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.
3- How will the chosen work get done?
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.

Sprint Review

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.
Key Points
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.
Product Owner Role in the Sprint Review
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.

Product Owner

Key Points
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"
The Product Goal
Is the Product Owner Vision, is a long term objective for the Scrum Team

Scrum Master

Key Points
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.
Scrum master serves the Scrum team by:
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.
Scrum master serves the Product Owner by:
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.
Scrum master serves the organi­zation by:
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

Sprint Retros­pective

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:
Definition of Done. {{nl}
This event is a good chance to add to the wealth and improve the definition of done.
Scrum Team discusses:
what went well during the Sprint
what problems it encoun­tered
how those problems were (or were not) solved. Key Points
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.


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          PivotalTracker Search Cheat Sheet
          SKP's Daily Agile Terms Cheat Sheet