- Table of Contents
- Useful Links
- Assessment Details
- Scrum Theory
- Scrum Artifacts
- Scrum Roles
- Scrum Events
- Definition of "Done"
These notes are heavily based off of Mikhail Lapshin's quiz.
From the PSM I Assessment page:
- Fee: $150 per attempt
- Passing score: 85%
- Time limit: 60 minutes
- Number of Questions: 80
- Format: Multiple Choice, Multiple Answer and True/False
- Difficulty: Intermediate
- Language: English only
- PSM Subject Areas
- Required course: None
- Recommended courses: Professional Scrum Foundations or Professional Scrum Master
- Practice Assessment: Scrum Open
- Passwords have no expiration date, but are valid for one attempt only
Note:
- 80 questions and 85% passing score means 68 or more questions must be answered correctly to pass.
- 80 questions and 60 minutes means 45 seconds per question
- The assessment is online and therefore 'open book'
-
Founded on empiricism
-
Comprised of
- Scrum Teams
- Roles
- Rules
- Events
- Artifacts
-
Pillars that uphold Scrum
- Transparency
- Inspection
- Adaption
-
Opportunities to Inspect and Adapt
-
Burn-down Charts show how much work remains till the end of the Sprint.
-
Cone of Uncertainty shows how much is known about the Product over time
-
Each component within the Scrum framework serves a specific purpose and is essential to Scrum's success and usage.
-
Scrum is not a process or a technique for building products. It is a framework within which you can employ various processes and techniques. It does not describe agile processes and techniques.
-
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
-
If an organization has decided to adopt Scrum but management wants to change the terminology
-
The length of a Sprint should be
- No more than one month
- Short enough to keep the business risk acceptable by the Product Owner
- Short enough to be able to synchronize the development work with other business events
-
Scrum does not require having aligned Sprints for multiple teams.
-
If the Development Team is not able to finish the complete forecast, the Product Owner and Development Team should review and adjust the Sprint work selected
-
Can be cancelled by only the Product Owner
- Any completed and Product Backlog Items are reviewed
- If part of the work is releasable the Product Owner accepts it
- Incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
- The Sprint is cancelled only if the Sprint Goal becomes obsolete
-
During the Sprint
- No changes are made that would endanger the Sprint Goal
- Quality goals do not decrease
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
-
During the first Sprint, the Development Team
- Delivers an increment of releasable software
- Develops and delivers at least one piece of functionality
-
Development Teams deliver an Increment of Product functionality every Sprint
- This Increment is usable so a Product Owner may choose to immediately release it
- Each Increment only contains "Done" functionality that could be released immediately
- It is not mandatory that the Increment be released to production at the end of each Sprint
- It is not normal to have a "hardening" Sprint to remove technical debt and prepare the Product for upcoming release
-
The Sprint is over when the time-box expires.
-
The next Sprint begins immediately after the conclusion of the previous Sprint.
-
Provides guidance to the Development Team on why it is building the Increment.
-
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.
-
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.
-
If the Sprint Goal becomes obsolete the Sprint may be cancelled.
- Scrum users must frequently inspect Scrum Artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
-
The Product Backlog items selected for this Sprint plus the plan for delivering them.
-
Created at the Sprint Planning.
-
Belongs solely to the Development Team
- Development Team members are never exclusive owners of a Sprint Backlog Item
- All Sprint Backlog Items are owned by the entire Development Team, even though each one may be done by an individual Development Team member
-
The Development Team modifies the Sprint Backlog throughout the Sprint
- The Development Team may learn more about the work needed to achieve the Sprint Goal
- As new work is required the Development Team adds it to the Sprint Backlog
- Only the Development Team may change the Sprint Backlog
-
If an item in the Sprint Backlog cannot be finished by the end of the Sprint it should be renegotiated between the Product Owner and Development Team.
- The Sprint is not cancelled in this case
-
Is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product
- Product Backlog Items are ordered with most valuable and clear items at the top
-
Used to describe the upcoming work on the product
- All Development Teams working together on the same product should be using the same Product Backlog
-
Is managed by the Product Owner
- The Product Owner is the sole person responsible for the Product Backlog
- The Product Owner can delegate some work related to Product Backlog management to the Development Team
- The Product Owner is responsible for the content, availability and ordering of the Product Backlog
-
Product Backlog refinement consumes no more than 10% of the capacity of the Development Team.
-
Features of a Product Backlog
- Never complete
- Evolves as the product and the environment in which it will be used evolves
- Dynamic — constantly changes to identify what the product needs to be appropriate, competitive, and useful
- As long as a product exists, its Product Backlog also exists
-
Product Backlog management includes
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
- Optimizing the value of the work the Development Team performs
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
- Ensuring the Development Team understands items in the Product Backlog to the level needed
-
The Increment is the sum of all the Product Backlog Items completed during the Sprint and the value of the increments of all previous Sprints.
-
Only members of the Development Team create the Increment.
-
The Scrum Team consists of
-
Scrum Teams are self-organizing
- Choose how to best accomplish their work rather than being directed by others outside the team
-
Scrum Teams are cross-functional
- Have all competencies needed to accomplish the work without depending on others not part of the team
-
There are three main qualities the Scrum Team is designed to optimize
- Flexibility
- Creativity
- Productivity
-
Characteristics of the Product Owner
- Product value maximizer
- Lead facilitator of Key Stakeholder involvement
- Product marketplace expert
-
Is responsible for managing the Product Backlog
- Maintains the content, availability and ordering of Product Backlog Items
- Can delegate some work related to Product Backlog management to the Development Team
- Most valuable and clear items are placed at the top of the Product Backlog
-
Is responsible for the monitoring of the remaining work towards the Project Goal
- Tracks total work remaining at least every Sprint Review
- Compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal
- This information is made transparent to all stakeholders.
-
Has the authority to cancel the Sprint
- Only the Product Owner has this authority
-
May be part of the Development Team if they are also executing the work of the Sprint Backlog.
-
There is only one Product Owner in a Scrum Team
- The Product Owner is one person
- They may represent the interests of a committee
-
The optimal Development Team size is between 3 and 9 people.
-
Product Owner and Scrum Master may be part of the Development Team if they are also executing the work of the Sprint Backlog.
-
Responsible for all estimates in the Product Backlog.
- The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
-
Creates the Increment.
-
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
-
Responsible for tracking the total work remaining in the Sprint Backlog and the likelihood of achieving the Sprint Goal
- This responsibility is solely the Development Team's and not the Product Owner's or Scrum Master's
-
Allowed to change the Sprint Backlog during the Sprint
- Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
-
Can be allowed to make changes to the Product Backlog if delegated by the Product Owner
-
Development Teams have the following characteristics
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
-
During the first Sprint, the Development Team
- Delivers an increment of releasable software
- Develops and delivers at least one piece of functionality
-
Serves the Development Team by
- Helping the Development Team to create high-value products
- Coaching the Development Team in self-organization and cross-functionality
- Removing impediments to the Development Team's progress
- Facilitating Development Team decisions
-
May be part of the Development Team if they are also executing the work of the Sprint Backlog.
-
Serves the organization by
- Planning Scrum implementations within the organization
- Leading and coaching the organization in its Scrum adoption
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
-
Does the following regarding the Daily Scrum
- Ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum
- Teaches the Development Team to keep the Daily Scrum within the 15 minute time-box
- Enforces the rule that only Development Team members participate in the Daily Scrum
-
Is a servant-leader for the Scrum Team
- Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't
- Helps everyone change these interactions to maximize the value created by the Scrum Team
-
Responsible for coping with incomplete artifact transparency.
-
Serves the Product Owner in several ways
- Finding techniques for effective Product Backlog management
- Helping the Scrum Team understand the need for clear and concise Product Backlog Items
- Understanding product planning in an empirical environment
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
- Understanding and practicing agility
- Facilitating Scrum Events as requested or needed
- Only two meetings in which people outside the Scrum Team are allowed to participate
- Sprint Planning
- The Development Team may invite other people to attend the Sprint Planning in order to provide technical or domain advice.
- Sprint Review
- The Product Owner is responsible for inviting the Key Stakeholders to the Sprint Review meeting
- Sprint Planning
- Allowed to participate in the Sprint Review meeting
- Not allowed to participate in any other Scrum Events
-
Time-boxed to a maximum of 8 hours for 1 month Sprints
- For shorter Sprints the event is usually shorter
-
Attended by the entire Scrum Team
- Product Owner, Development Team and Scrum Master all attend
- Other people may be invited to attend in order to provide technical or domain advice
-
Answers
-
Does not answer
- Who will be responsible for each item in the Sprint Backlog?
- What new technologies could be used to speed up the Development Team velocity?
- What is the size of the Technical Debt and how it could be removed?
-
Inputs to the Sprint Planning are
- The Product Backlog
- The latest product Increment
- Projected capacity of the Development Team during the Sprint
- Past performance of the Development Team
-
Only work planned for the first days of the Sprint is required to be decomposed to units of one day or less.
- The Development Team should be able to explain to the Product Owner and Scrum Master how it indends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment
-
Time-boxed to 15 minutes
- No matter the size of the Development Team
-
Only the Development Team can participate
- Other people could attend but cannot participate
-
Cannot be skipped
-
Opportunity for the Development Team to synchronize activities and create a plan for the next 24 hours
-
Three main questions each member of the Development Team should answer
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
-
Time-boxed to a 4 hour meeting for 1 month Sprints
- For shorter Sprints the event is usually shorter
-
Attended by
- The Scrum Team
- The Product Owner
- The Development Team
- The Scrum Master
- Key Stakeholders
- The Scrum Team
-
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
-
Time-boxed to a 3 hour meeting for 1 month Sprints
- For shorter Sprints the event is usually shorter
-
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
-
The purpose of the Sprint Retrospective is to
- Inspect how the last Sprint went with regards to people, relationships, process, and tools
- Identify and order the major items that went well and potential improvements
- Create a plan for implementing improvements to the way the Scrum Team does its work
-
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of "Done" as appropriate.
-
The Development Team is responsible for the creation of the Definition of "Done"
- If the Definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
- If "done" for an increment is not a convention of the development organization, the Development Team of the Scrum Teams must define a Definition of "Done" appropriate for the product.
- If there are multiple Scrum Teams working on the system or product release, the Development Teams on all of the Scrum Teams must mutually define the Definition of "Done""
-
Helps the Scrum Team
- Definition of "Done" is used to assess when work is complete on the product Increment
- Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
- Definition of "Done" ensures artifact transparency
-
Accounts for
- Conventions, standards and guidelines of the Organization
- Definition of "Done" of other Scrum Teams working on the same Product
-
Does not account for
- Definition of "Done" of other Scrum Teams working on other products
- Experience of the Product Owner
- Advice of the Scrum Master
-
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of "Done" as appropriate.