SCRUM Guide
SCRUM Guide
1 Scrum guide
1.1 The 2020 Scrum Guide
This HTML version of the Scrum Guide is a direct port of the November 2020 version available as a PDF here or original 2013.
1.2 Agile-essentials SCRUM overwiew
- Resource Center
- The Scrum Framework by Scrum Inc..
- Suggested Reading for Professional Scrum Master
- Guia rápida implementar SCRUM
1.3 Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Through this work we have come to value
1.3.1 3-Pillars
Transparency, Inspection and adaptation
1.3.2 4-Foundations
- Individuals and interactions over processes and tools
- Working software over comprehensive documentatio
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
1.3.3 12-Principles
2 Artifacts
In archeology, an artifact is an object of cultural significance. In medicine, artifacts are something not normally present, or unexpected. In Scrum, our use of the word “artifact” is closer to the way software developers use it: important information needed during the development of a product.
Scrum has three artifacts:
- Product Backlog
- Sprint Backlog
- Increment
2.1 Backlog
Number of Story Points completed per Sprint
is an always changing, dynamically prioritized list of requirements ordered by Business Value. Requirements are broken down into User Stories by the Product Owner. Definition of Done (DoD) at the Backlog level.
contains all committed User Stories for the current Sprint broken down into Tasks by the Team. All items on the Sprint Backlog should be developed, tested, documented and integrated to fulfill the Team commitment.
shows the amount of work remaining per Sprint. It shows the correlation between work remaining at any point in time and the progress of the Team.
3 Core concepts: invest - user story - done - poker
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story.
A good user story should be:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
For a user story, the next template should be used:
a user story that covers large amounts of functionality. Because an epic is generally too large for an Agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on
is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
list of activities that must be fulfilled in order to consider US done
also called Scrum poker, is a consensus-based, gamified technique for estimating by playing numbered cards face-down to the table, instead of speaking them aloud.
4 Events
The Scrum events are key elements of the Scrum Framework. They provide regular opportunities for enacting the Scrum pillars of Inspection, Adaptation and Transparency. In addition, they help teams keep aligned with the Sprint and Product Goals, improve Developer productivity, remove impediments and reduce the need to schedule too many additional meetings.
There are five Scrum events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), each with their own purpose, time constraints and participants.
4.1 Purpose
While learning the details of each is very important for effective Scrum, at the highest level*, the purpose of each is actually quite simple:
- Sprint - All work in Scrum is done in a series of short projects called Sprints. This enables rapid feedback loops.
- Sprint Planning - The Sprint starts with a planning session in which the Developers plan the work they intend to do in the Sprint. This plan creates a shared understanding and alignment among the team.
- Daily Scrum - The Developers meet daily to inspect their progress toward the Sprint Goal, discuss any challenges they’ve run into and tweak their plan for the next day as needed.
- Sprint Review - At the end of the Sprint, the Sprint Team meets with stakeholders to show what they have accomplished and get feedback.
- Sprint Retrospective - Finally, the Scrum Team gets together to discuss how the Sprint went and if there are things they could do differently and improve in the next Sprint.