SCRUM GUIDE - PSM I
131 1 2
This mind map is about SCRUM GUIDE - PSM I. Start to use a mind map to express and organize your ideas and knowledge right now.
Similar Mind Maps
SCRUM GUIDE PSM I
SPRINT BURNDOWN CHART
The horizontal axis (sprints); the vertical axis (amount of work remaining at the start of each sprint).
Burndown charts track rok remaining acrosstime
DEFINITION OF SCRUM
Is a process framework within which people can address complex and adaptiveproblems
Lightweight, Simple to understand, Difficult to master
Is not a process, technique or definitive method
Provide effective in interative and incremental knowledge transfer
The essence of Scrum is a small team of people highly flexible and adaptive
SCALING SCRUM NEXUS
For multiple teams working on the same project, the sprint start date doesn&#39;t have to be the same
Adding new Scrum team to a project
Productivity of the original team will decrease cause memberswill have to learn how to work on the same backlog and PO
A common language shared by all participants
A common definition of &quot;Done&quot; must be shared for by those performing and inspecting the work
Scrum users must inspect Scrum Artifacts and progress to identify deviation
The frequency of inspection shouldn&#39;t interfere with the work
Adjustments must be done as soon as possible to minimize further deviation
There are 4 formal events for inspection and adaptation (Sprint Planning, Daily Scrum, Sprint Review, SprintRetrospective).
DEFINITION OF &quot;DONE&quot;
Who defines it
The Dev Team (if there is no definition)
*the Dev Team must conform to the definition
Is used to assess when work is complete on the product Increment
It guides the Dev Team in knowing how many items it can select during a Sprint Planning
It ensures artifact transparency.
* Members must have a shared understand of what &quot;Done&quot; means.
* If there is a definition of &quot;Done&quot; for the organization, all Scrum Teams must follow it
* If there is not a definition of &quot;Done&quot; for the organization, Dev Team must define it
Mature Scrum Teams
Definition of &quot;Done&quot; will expand to include more stringent criteria for higher quality
Multiple Scrum Teams
Dev Teams on all Scrum Teams must mutually define the definition of &quot;Done&quot;
When item is considered &quot;done&quot;
when the item has no work remaining to be released
No work left from the definition of &quot;done&quot;
all work to create an usable software
Must work with others to understand if the artifacts are transparent
Must help everyone apply practices in the absence of complete transparency
Can detect incomplete transparency by inspecting artifacts, sensing patterns, differences between what is expected and real results
Should work with the Scrum them and the organization to increase transparency of the arctifacts
Represent work or value to provide transparency and opportunities for inspection and adaptation
Designed to maximize transparency of key information (everybody has the same understanding of it)
An ordered list of all features, requirements, improvements and fixes that constitute changes to the product in future releases.
Is the single source of requirements for any changes to be made to the product
Is never complete, is dynamic, constantly changes to identify what the product needs to be appropriate, useful and competitive.
Items have the attributes of a description, order, estimate, and value.
* As a product is used, the Product Backlog becomes a larger list, cause market provides feedback of it
The PO is responsible for its content, availability, and ordering
Is the act of adding detail, estimates and order to items
Is an ongoing process in which PO and Dev Team collaborate on details of the items
* Scrum Team decides how and when refinement is done (usually consumes 10% of the capacity of the Dev Team)
* Items can be updated at any time by the PO
Level of Details
Higher ordered items are usually clearer and more detailed than lower ordered ones.
Items ready for selection in a Sprint Planning (refined and can be &#39;done&#39; by the Dev Team within one sprint)
The Dev Team is responsible for all estimates (PO may influence by helping it understand)
PO tracks the total work remaining to reach a goal at least at every Sprint Review
PO compares it to previous Sprint Reviews to assess progress
*Projective practices like Burn-downs are useful. However, this does not replace empiricism (only what hashappened can be used for forward-looking decision-making).
* Multiple scrum Teams often work on the same product and the same Product Backlog
A Product Backlog attribute that groups items may then be employed
Is the set of Product Backlog items selected for the sprint plus a plan for delivering an Increment and meeting the Sprint Goal
Is a forecast by the Dev Team of what functionality will be in the next increment and the work necessary to delivery it
It includes at least one high priority process improvement identified in the previous Retrospective meeting.
Only the Dev team can change its Sprint Backlog
Dev team modifies the Sprint Backlog thoughout the Sprint, and the Sprint Backlog emerges during the Sprint
If elements are deemed unnecessary are removed from the plan
The Dev Team in agreement with the PO define the Sprint Backlog Scope
Monitoring Sprint Progress
Dev Team tracks the work remaining in every Daily Scrum and can manage its progress
Used in Daily Scrum as a reference to understand changes in progress
Sum of all product backlog items completed in the Sprint and the value of the increments of all previous sprints
The increment is an step toward a goal.
How to increase transparency
Doing all work needed to meet the definition of &quot;Done&quot;
Updating Sprint tasks properly in the tracking tool
* It must be in useable condition regardless of whether the PO decides to release it
* It must meet the definition of &quot;Done&quot;
to achieving the goals of the team
to do the right thing and work on complex problems
on the work of the sprint and the goals of the team
about the work and challenges
each other to be capable, independent people.
Self-organized: choose how best to accomplish their work
Cross-functional: have all competencies needed to accomplish the work without depending on others.
Designed to optimize flexibility, creativity and productivity
Responsible for promoting and supporting Scrum (manages the scrum framework)
Servant-leader for the ScrumTeam
Helps everyone in understanding Scrum theory, practices, rules and values.
Helps those outside of the team to understand helpful and bad interactions with the Scrum team.
Helps everyone change interactions with the Scrum team to maximize the value created.
Service to the PO
Finding techniques for effective Product Backlog Management
Ensuring that the PO knows how to arrange the Product Backlog
Understanding and practicing agility
Facilitating Scrum events
Service to the Dev Team
Coaching self-organization and cross-functionality
Helping to create high-value products
Facilitating Scrum events
Service to the Organization
Leading and coaching Scrum adption
Planning Scrum implementations
Helping employees and stakeholders understand and enact Scrum
Causing change that increases the productivity of the team
Working with other SM to increase the effectiveness of the implementation of Scrum
Professionals who do the work of delivering a potentially releasable Increment each sprint
Structured to manage their own work, optimizing the team&#39;s overall efficiency and effectiveness
*Someone in the Dev Team can also play SM&#39;s role
Only members of the Dev Team create the increment
Responsible for tracking the remaining work of the Sprint
Team Size (3 to 9)
fewer than 3 (decrease interaction, skills constraints, smaller productivity gains)
more than 9 (requires too much coordination, generates complexibility for an empirical process)
no titles for the members
no sub-teams in the Dev team
members may have specialized skills and areas of focus, butaccountability belongs to the Dev Team as a whole
a sole person not a committee
Management of the Product Backlog:
clearly expressing items
optimizing the value of the product resulting from work of the Dev Team
ensuring transparency and clear to all, and what the team will do next
ensuring the Dev Team understand items;
*The Dev Team can do it, but the PO is accountable for it.
-Ensure that the most valuable functionality is produced first
Interacting with stakeholders
*The entire organization must respect the PO decisions.
*Can delegate some activities to someone else
*For a single product there should be 1 product Backlog and 1 PO (he can delegate some activitiesto the team)
Is a specific amount of days for a team to work at a sustaibnable pace to finish selected work
Used to create regularity and to minimize the need for meetings not defined in Scrum
Time-boxed (maximum duration, cannot be shortned or lengthened)
End whenever the purpose of the event is achieved
Is a formal opportunity to inspect and adapt something
to create a &quot;done&quot;, useable and potentially releasable product increment
1 month or less
(if the horizon is too long, the definition of &quot;done&quot; may change, complexity and risk may increase).
*Is better to have sprints of consistency length
Time-boxing promotes self-organization by:
helping everyone to focus on the same problem at the same time
encouraging people to creat the best result in the given time
the Sprint Planning, Daily Scrum, the development work, Sprint Review and the Sprint Retrospective.
Starts right after the previous sprint
During a Sprint
Changes that affect the sprint goal are not made;
Quality goals do not diminish;
Scope may be cleared up and negotiated between the PO and Dev Team.
Predictability by ensuring inspection and adaptation of progress toward a sprint goal every 1 month
Limit risk to 1 month of cost;
Cancelling a Sprint
only the PO can cancel it (sometimes under influence from others)
If the sprint goal becomes obsolete (company changes direction or market / technology conditions change)
If no longer makes sense to keep it
Completed and Done Items
are reviewed (PO checks if part of the work is potentially releasable)
Are re-estimated and sent back to the Product Backlog
Are not included in the Sprint Review
Consumes resources and is often traumatic and very uncommon
Defining Sprint Length
Level of uncertainty over the technology that is going to be used
Risk of being disconnected from the expectations of stakeholders
The ability to go to market with a product release
Plan the work to be performed in the Sprint
entire Scrum Team
*People outside scrum are also allowed
8h for one-month sprints
What can be delivered in the Increment of the Sprint?
PO discusses the objective of the sprint and items that, if completed, would achieve the sprint goal.
Dev Team forecasts the functionality that will be developed
Entire Scrum Team collaborates on understanding the work of the Sprint
Dev Team (only) defines number of items selected from the product Backlog
How will the work needed be achieved?
Dev Team decides how it will build the functionality into a &#39;done&#39; product increment;
Dev Team usually starts by designing the system and the work needed to convert the backlog into an Increment;
Work planned for the first days of the sprint is decomposed by the end of this meeting to units of one day or less;
PO can help to clarify selected items and and make trade-offs.
*Dev Team can invite other people to attend to provide technical or domain advice.
Product backlog, latest product increment, projected capacity of the Dev Team, past performance of the Dev Team.
objective set for the sprint that can be met through the implementation of the product backlog
provides guidance to the Dev Team and gives some flexibility
causes the Dev Team to work together rather than on separated initiatives
*The Scrum Team defines the Sprint Goal
product backlog items selected + plan for delivering them
*if necessary, PO and Dev Team collaborates to re-negotiate the scope of the sprint backlog within the sprint.
-ensures that the event takes place
-attendees understand its purpose
-teaches to keep the event whithin the time-box
Plan the work for the next 24 h
Inspect progress toward the sprint goal
inspect how progress is trending toward completing the work in the sprint backlog
Dev Team (defines the structure of the meeting and is responsible for conducting it)
every day of the Sprint (at the same time and place to reduce complexity)
Optimize the probability of meeting the Sprint goal
Improve communications, eliminate other meetings, identify impediments, promote quick decision making;
Optimize team collaboration and performance by inspecting the work
Key inspect and adapt meeting.
Exemple of Question based meeting
What did I do yesterday that helped the Dev team meet the sprint goal?
What will I do today to help the Dev team meet the sprint goal?
Do I see any impediment that prevents me or the Dev team from meeting the sprint goal?
Role of the SM
Ensures that the meeting happens;
Teaches the Dev team to keep the meeting within the time-box
Ensure that others do not disrupt the meeting
a shared understanding of the most important work to be performed next to achieve the sprint goal
new impediments for the SM remove
Inspect the increment and adapt the Product Backlog if necessary
Attendees collaborate on what was done and the next things that could be done to optimize value
To demonstrate the Product Backlog items completely &quot;done&quot; and to receive feedback from the PO
*Informal meeting, not a status meeting
Scrum Team and Stakeholders invited by the PO
*People outside scrum are also allowed
at the end of the Sprint
4h for one-month sprint
PO explains what items have been &#39;done&#39; and not been &#39;done&#39;;
Dev Team discusses what went well and problems it ran through;
Dev Team demonstrates the work &#39;done&#39; and answers questions about the increment;
PO discusses the current Product Backlog and projects targets and delivery dates;
Attendees collaborate on what to do next (valuable input to the next Sprint Planning);
Review changes in marketplace and potential use of the product;
Review timeline, budget, capabilities and marketplace for the next releases of functionalities.
Revised Product Backlog with probable items for the next Sprint
Adjusted Product Backlog to meet new opportunities
Role of the SM
Ensures that the event takes place
Attendees understand its purpose
Teaches to keep the event whithin the time-box
opportunity for the Scrum team to inspect itself and create a plan for improvements during the next sprint.
Inspect the last sprint considering people, relationships, process and tools;
Identify and order major items that went well and potential improvements;
Create a plan for implementing improvements in the Scrum team;
SM, Dev Team, PO
3h for one month sprints
after the Review Sprint and prior to the next Sprint Planning
Plan to increase product quality (by improving work processes or adapting the definition of &quot;Done&quot;)
Improvements identified to be implemented in the next Sprint
* Improvements may be implemented at any time, the Retrospective is a formal opportunity to focuson inspection and adaptation.
Role of the SM
Participates as a peer team member (accountability over the Scrum process)
Ensures the meeting is positive and productive
Encourages the Scrum Team to improve its development process and practices
Teaches all to keep it within the time-box
Scrum doesn&#39;t recommend tools or estimation methods
Implementing only parts of Scrum is possible, but the result is not Scrum
Essence of Scrum: a small team of people highly flexible and adaptive
Scrum allow additional meetings not defined in Scrum
Promotes selforganization by
being a lightweight framework
removing titles for Dev Team members
Dev Team deciding what work to do in a Sprint