Scrum PSM I - Notes
Tags: scrum, management, agile
Published: 2020-04-30 08:08:17



# Scrum Framework Theory

- Scrum is a  **framework**  for developing complex products. It&#39;s not a technique or a definitive method.
- Scrum addresses  **complex**  **adaptive**  **problems** , while productively and creatively delivering products of the **highest possible value.**
- Scrum is lightweight, simple to understand but difficult to master.
- The Scrum framework consists of **Scrum Teams** (small team of people) and their associated **roles** , **events** , **artifacts** , and **rules**.
- Scrum is used in very diverse areas, from developing software and hardware to managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
- Scrum is founded on empirical process control theory, or  **empiricism**.
  - Empiricism asserts that knowledge comes from **experience**.
- Three pillars uphold every implementation of empirical process control:  **transparency, inspection, and adaptation** (TIA).
  - **Transparency** – Significant aspects of the process must be **visible** to those responsible for the outcome. Observers need have a common understanding of what is being seen.
  - **Inspection** – Scrum users must **regularly inspect** Scrum artifacts (product backlog, sprint backlog, the increment) and progress toward a Sprint Goal to detect undesirable results
  - **Adaptation** – As soon as a **deviation** from the expect result is determined, an adjustment must be made as soon as possible. Scrum prescribes four formal **events for inspection and adaptation** : Spring Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- The Scrum Values are:  **commitment, courage, focus, openness and respect** (CCFOR). These values are important to bring to life the three pillars of Scrum and build **trust** to everyone.
  - **Commitment** – Everyone personally commit to achieve the goals of the team.
  - **Courage** – Everyone have courage to do the right thing and work on tough problems.
  - **Focus** – Everyone focuses on the work of the Sprint and the goals of the team.
  - **Openness** – The team and the stakeholders agree to be open about all the work and the challenges to perform it.
  - **Respect** – Everyone respect each other to be capable, independent people.

# The Scrum Team

- Consists on a **Product Owner**, the **Development Team**, and a **Scrum Master**.
- Scrum Teams are:
  - **Self-organizing** – Choose how best to accomplish their work.
  - **Cross-functional** – Everyone has all competencies needed to accomplish the work without depending on others that are not part of the team.
- The team model is **designed** to optimize **flexibility** , **creativity** , and **productivity**.
- There is no Project Manager role in Scrum and in general, the Product Owner role is by no means to be confused with a Project Manager. The responsibilities of a Project Manager are distributed between the Product Owner, the Scrum Master and the rest of the team.

## Product Owner

- The main responsibility is to **maximize the value** (this value could come in various forms) of the product resulting from work of the Development Team.
- Is only **one person**, not a committee. But can represent the desires of a committee.
- Is the **sole person** responsible for managing the **Product Backlog** :
  - The items on the Product Backlog should be clearly expressed and understood by the Development Team.
  - Is responsible for ordering the items in the Product Backlog.
  - Ensure that the Product Backlog is visible, transparent, and clear.
  - The Product Backlog should show what the Scrum Team will work next.
- The Product Owner may do the above work or have the Development Team do it. However, the Product Owner still remains accountable.

## Development Team

- Their goal is to deliver a **potentially releasable Increment of &quot;Done&quot;** product at the end of each Sprint.
- Only the Development Team can create the **Increment**.
- The Development Team is **structured and empowered by the organization** to organize and manage their own work.
- The teams are **self-organizing**. Only they made the decisions in how the Product Backlog should be turned into potentially shippable Increments. The benefits are **commitment** , **accountability** and **creativity**. Also optimizes **flexibility**.
- They are **cross-functional** (the team should have the skills needed to create the Increment). There is **no titles** in Development Team, even if the work is done for someone. So, the **accountability belongs to the Development Team as a whole**.
- It is possible for the Product Owner or the Scrum Master to be part of the Development Team, but not recommended.
- The Development Team should have between **3 to 9 team members**.

## Scrum Master

- The Scrum Master assists the Development Team and the Product Owner and is responsible for **promoting and supporting** Scrum within the organization. The Scrum Master ensures that everyone understands the Scrum theory, practices, rules and values.
- The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change.
- The Scrum Master is not a manager, but more like a servant leader.
- Scrum Master service to the **Product Owner** :
  - Understanding **Scrum and Agile practices**.
  - Ensuring that **goals, scope and product domain** are understood.
  - Learn effective **Product Backlog management**.
  - **Product planning** in an empirical environment.
  - Can **facilitate** planning and Backlog refinement.
- Scrum Master service to the **Development Team** :
  - Coaches in **self-organization** and **cross-functionality**.
  - Helps to create **high-value products**.
  - Remove **impediments**.
  - **Facilitating** Scrum events (not a secretary).
  - **Coaching** the Scrum values.
- Scrum Master service to the **Organization** :
  - **Coaches** the organization.
  - **Works with other** Scrum Masters.
  - **Cause changes** that increase the productivity of the Scrum Team.
  - **Coaches Scrum** and empirical product development.

# Scrum Events

## Sprint

![Scrum Framework](https://dev-to-uploads.s3.amazonaws.com/i/xlgxl9qys4r9ncihpa5v.png)

- Timebox of **one-month or less**. Short enough to keep the business risk acceptable to the Product Owner, and able to synchronize the development work with other business events.
- Sprints contain all the prescribed Scrum Events, a flexible plan on how to build a Product Increment and of course the development work needed.
- Each Sprint has the **Sprint Goal** that helps the Development Team better understand why it is building the **Increment**.
- 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.
- There is no gap between Sprints and nothing happens between Sprints.
- A Sprint **can be cancelled** (very rare).
  - **Only the Product Owner** can do it.
  - This can happen if:
    - The Sprint Goal becomes obsolete.
    - Major changes in the market occur.
    - Company decides to change direction.
  - If it&#39;s canceled:
    - **Completed** items will be reviewed.
    - **Incomplete** items will be re-estimated and put back in the Product Backlog.

## Sprint planning

- Time-boxed to a maximum of **eight hours for a one-month Sprint**.
- Normally happens after the conclusion of the previous Sprint.
- Answers the following:
  - **What can be delivered** in the Increment resulting from the next Sprint.
  - **How will the work** needed would be achieved.
- A **Spring Goal** is defined by the Product Owner and the Development Team. Even if the objective of the Sprint Goal is at first defined by the Product Owner, the number of the Product Backlog items selected is solely up to the Development Team (upon negotiation with the Product Owner). To define this, the following is evaluated:
  - Previous Product Increment
  - Projected capacity of the Development Team.
  - Past performance of the Development Team.
- The Development Team **can invite people outside** the Scrum Team to provide technical or domain advice.
- This meeting cannot identify all the work that needs to be done in advance. **Only a plan with enough detail so that the development work can start**. By the end of the meeting, this plan should be decomposed often to units of one day or less. The Development Team should be able to explain their plan to accomplish the Sprint Goal.
- At the end of the meeting, this should be defined:
  - The Spring Goal
  - The Product Backlog items selected and the plan for delivering them (this is the Spring Backlog)

## Daily Scrum

- Time-boxed of **15 minutes**, every day and at the same time and place.
- **Only the Development Team** attends this meeting. They could allow others to be present, and the Scrum Master has the role to make sure that the team has the meeting.
- It&#39;s a key to **inspect** and **adapt** pillars
- The Development Team inspect progress toward completing the work in the Sprint Backlog and reaching the Sprint Goal.
- The interactions that the Development Team has should improve communication, identify impediments and promote quick decision making.
- Examples of questions to be answered:
  - What did I do yesterday?
  - What will I do today?
  - Do I see any impediment?
- If needed, the Development Team can meet immediately after the Daily Scrum to further discuss and decide on how do the rest of the Sprint work will be completed.
- This meeting should result in a common understanding of how the Sprint is progressing and what needs to be done next to meet the Sprint Goal.

## Spring review

- Time-boxed to a maximum of **four**  **hours for a one-month Sprint**.
- Happens at the end of a Sprint to **inspect** the Increment and **adapt** the Product Backlog if needed.
- The **Product Owner owns this meeting** and will invite key Stakeholders to this event. The Development Team and the Scrum Master are also present. The Scrum Master role is to **facilitate** this meeting and to make sure it is **held** within the time-box.
- It&#39;s an **informal** meeting.
- The **items that have been Done and not Done are explained by the Product Owner**.
- The **Development Team discusses** what went well, what were the problems, and how these problems can be resolved.
- The **Development Team demonstrates** the work that is been Done
- The **Product Owner discusses the Product Backlog** and explains when the next release might be available.
- The **entire group collaborates** on what to do next, discusses changes in the marketplace and what is important to do next.
- This meeting can **result** in a revised Product Backlog. The items that were not done, are put back in the Product Backlog.

## Spring Retrospective

- Time-boxed to a maximum of **three hours for a one-month Sprint**.
- It&#39;s the **last event** before the end of the Sprint. Happens after the Sprint Review and before the Sprint Planning.
- The goal of the Sprint Retrospective is for the Scrum Team to **inspect** itself and the process, and **create a plan** for improvements for the next sprint.
- **Only the Scrum Team** is present.
- The Scrum Master is a **facilitator** in this meeting, makes sure that everybody understands the purpose and ensures that the meeting is positive and productive and coaches a team to keep the event within the time-box.
- The objective is to look into **how the last Sprint went** with regards to people, relationships, processes, and tools.
- **Get reflections** on what went well and what can be improved.
- **Create a plan** for implementing those improvements in the next Sprint.
- The **Definition of Done** could be **improved**.
- The **result** of this meeting is the improvements that the Scrum Team will implement in the next Sprint.

# Scrum Artifacts

## Product Backlog

- An **ordered list of everything that is known** to be needed in the product.
- Artifact designed to provide **transparency** and opportunities for **inspection** and **adaptation**.
- **Single source** of all features, functions, requirements, enhancements and fixes for any future changes to be made to the product. As long as the product exists so will its Product Backlog.
- Never complete and constantly changing.
- The **Product Owner is the only responsible** for the Product Backlog.
- If multiple teams who work on the same Product, **only one** Product Backlog should be used.
- The Product Backlog items **characteristics** are description, order, estimate and value. Could also have a test description.
- The **Development Team is responsible** for the **estimates**.
- Product Backlog items that are positioned higher in the Product Backlog are more important as they provide much greater value and are usually clearer and more detailed as the items in the lower part of the Product Backlog. The top items are more refined, so they should be small enough to be included in the next Sprint.
- The Product Backlog **refinement** is the act of adding detail, estimates, and order to items. Time-boxed event that should not occupy more **than 10 per cent of the capacity** of the Development Team.

## Sprint Backlog

- Set of **Product Backlog items selected for the Sprint**, plus a **plan** for delivering the Increment and achieve the Sprint Goal.
- The Sprint Backlog should also **include at least one important process improvement** identified during the last Sprint Retrospective.
- **Temporary Artifact** that exists only during the Sprint.
- The **Development Team is the only responsible** for the Sprint Backlog. If new work is required, the Development Team adds it.
- The scope may be **clarified and re-negotiated** between **the Product Owner** and Development Team as more is learned.
- As work is performed or completed, the estimated remaining work is updated.
- The Development Team is responsible for monitoring the progress and the likelihood of reaching the Sprint Goal. This should be tracked at least in every Daily Scrum.

## Increment

- Is the **sum of all Product Backlog Items completed** during a Sprint, plus the value of **all Increments from all previous Sprints**.
- At the end of each Sprint, the Increment must be **completed** according to the **Definition of Done**.
- The **Product Owner is the responsible** for if and when to **release the Increment**.

### Definition of Done

- Every member of the Scrum Team must have a **shared understanding** of what it means for **work to be complete**, to ensure **transparency**.
- **The purpose of each Sprint is to deliver** increments that **respect the current definition of Done**.
- Guides the Development Team in knowing how many Product Backlog items it can select for the Sprint Backlog
- Who creates the Definition of Done?
  - The **Development Organization** - Typically most organizations have already development processes in place, standards that must be followed, procedures and quality standards. If there is no convention by the organization, should be the development team to define it.
  - The **Development Team**
    - The Development Team of the Scrum Team **must define** a definition of Done appropriate for the Product **if there is none** defined by the development organization.
    - The Development Team **may involve the Product Owner** in this process and may define rules and quality criteria that are stricter but still following the Definition of Done that the organization has.
    - If there are multiple Scrum Teams, **all Development Teams should agree on a definition of Done**.

# Scrum Terms

## Burn-down Chart

- A chart which shows the amount of work which is thought to remain a backlog.
- Is only related to the remaining work.
- Isn't related to project costs or business value, nor related to the productivity of the Development Team.

![https://www.leerichardson.com/2008/10/forget-burndown-use-burnup-charts.html](https://dev-to-uploads.s3.amazonaws.com/i/i5heo2h9sdxspqrcoo5p.gif)

## Burn-up Chart

- A chart which shows the amount of work which has been completed.
- Provides a visual representation of a Sprint&#39;s completed work related to its total scope, which is represented by the number of selected Product Backlog Items

![https://www.leerichardson.com/2008/10/forget-burndown-use-burnup-charts.html](https://dev-to-uploads.s3.amazonaws.com/i/kgitsvr0chum3wujuk2u.gif)

## Cone of uncertainty

- Describes the evolution of the amount of uncertainty during a project.
- As more is learned, uncertainty tends to decrease.

## Technical debt

- The typically unpredictable overhead of maintaining the product, ofter caused by less than ideal design decisions. Also known as Design Debt or Code Debt.
- May exist unintentionally in the Increment or introduced purposefully to realize value earlier.
- Technical Debt is something that should be continuously dealt with and not postponed.
- Technical Debt is tightly coupled with the quality of the product.

## Velocity

- Is a measure of the amount of work a Development Team can handle during a typical Sprint.
- Is not mandatory in Scrum, and not correlated with value. Only estimates are made, no commitment is done.

Sources:

- [Scrum Guide](https://www.scrum.org/resources/scrum-guide)
- [Scrum Master Certification Preparation & 240+ Prep Questions, Udemy Course, Valentin Despa](https://www.udemy.com/course/scrum-master-certification-preparation-mock-exam-questions-psm-i)
- [Scrum Quizzes, Mikhail Lapshin](https://mlapshin.com/index.php/scrum-quizzes)
- [Forget Burndown Use Burnup Charts, Lee Richardson](https://www.leerichardson.com/2008/10/forget-burndown-use-burnup-charts.html)