> For the complete documentation index, see [llms.txt](https://kdongs.gitbook.io/kdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kdongs.gitbook.io/kdocs/scrum/basics.md).

# Basics

## Scrum

{% embed url="<https://www.scrum.org/open-assessments/scrum-open>" %}

* A mechanism to ***optimize*** the value ***delivery system***.
* Scrum is used to drive the work and effort we take to deliver value in complex environments.
* Is a way to help deal with complex problems.
* ***Is a mechanism to guide changes.***

<mark style="background-color:yellow;">So scrum is a agile framework that you can use as a foundation to work on complex problems.</mark>

* Not a process.
* Or technique.
* Or methodology.
* Or definitive method.

<mark style="background-color:yellow;">But it is a general-purpose that MUST be complemented given your domain.</mark>

**Why scrum is a framework?**

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2F6B76Hs6xHQVTCdwCuOvZ%2Fflow-chart-complete.png?alt=media&amp;token=11d6700f-8523-4d90-afeb-dc3ada3b636a" alt=""><figcaption></figcaption></figure>

Because, it can be improved upon.

### What is complexity

Can be defined with two dimensions:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><p><strong>What</strong> needs to be done.</p><p>(<em><strong>The "What" dimension</strong></em>)</p></td><td></td><td></td></tr><tr><td><p><strong>How</strong> to do it.</p><p>(<em><strong>The "How" dimension</strong></em>)</p></td><td></td><td></td></tr></tbody></table>

#### Types of problems

* Simple problems:
  * Easy to predict what it needs AND to develop.
* Complicated problems:
  * Easy to define, but difficult to come to an agreement on how to solve it.
  * Or easy to solve, but hard to get to an agreement on what needs to be done.
* ***Complex problems***:
  * <mark style="background-color:yellow;">In a complex environment, you only know 1 thing for sure: You don't know everything.</mark>
  * <mark style="background-color:yellow;">You cannot early in the process predict if you are going in the right path.</mark> *(You will have to change along the way)*
* Chaotic problems.

#### Types of Changes

There are two perspectives:

* <mark style="background-color:yellow;">Effectiveness</mark>:
  * ***Delivering the right product.*** (*The "What" dimension*)
* <mark style="background-color:yellow;">Efficiency</mark>:
  * (*The "How" dimension*)

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FK2ltAcuN0TrrNWT7Jff4%2Fbasic-contecepts.png?alt=media&amp;token=f188bfbf-a21d-4d28-937f-a35a4fbffe5a" alt=""><figcaption></figcaption></figure>

#### Nonfunctional Requirements (NFRs)

Define system attributes such as:

<table data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Security</strong></td><td></td><td></td></tr><tr><td><strong>Reliability</strong></td><td></td><td></td></tr><tr><td><strong>Performance</strong></td><td></td><td></td></tr><tr><td><strong>Maintainability</strong></td><td></td><td></td></tr><tr><td><strong>Scalability</strong></td><td></td><td></td></tr><tr><td><strong>Usability</strong></td><td></td><td></td></tr></tbody></table>

They serve as constrains or restrictions on the design of the system across the different backlogs.

* There are ALWAYS nonfunctional requirements.
* They should be incorporated into every Increment.
* Some of them can be added to the Definition of Done.
* Some of them can be added to the Product Backlog.

#### PMOs

In a company that uses Scrum and has PMO, the PMO proper role is:

* Manages portfolios and programs and facilitates the application of techniques that complement Scrum.

***

## Agile and Scrum relationship

<mark style="background-color:green;">Scrum is a way of implementing agility.</mark>

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FXwPOLQrZ4CQCDdaVCUxY%2Fagile-scrum-relationship.png?alt=media&amp;token=072dc335-4980-4042-95c3-cc937037f5d1" alt=""><figcaption></figcaption></figure>

Studies show that 60% of the teams that claim to be agile, use Scrum as its core framework.

***

## Scrum Definition in a Nutshell

Scrum requires a ***Scrum Master*** to foster an environment where:

* A ***product owner*** orders the work for a complex problem into a ***product backlog***.
* The scrum team turns a selection of the work into an ***increment*** of value during a Sprint.
* The ***scrum team and its stakeholders inspect the results*** and adjust for the next Sprint.
* Repeat.

The scrum framework is purposefully incomplete, only defining the parts required to implement scrum theory.

### How scrum works (Flow)

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FsnCeOnSrvwsEEibnJAyL%2Fscrum-flow.png?alt=media&amp;token=b2355e23-7cf8-4ecc-8dca-9dea00d0071d" alt=""><figcaption></figcaption></figure>

This iterative and incremental process is executed until work is done or budget is over and includes refining the product backlog as needed.

**Product Backlog**

* It all starts with the product backlog, which <mark style="background-color:yellow;">contains all the work to be done</mark>, and <mark style="background-color:yellow;">describes what will fulfill the</mark> <mark style="background-color:yellow;"></mark>*<mark style="background-color:yellow;">**product goal**</mark>*.
* It is maintained by the Product Owner (PO), who makes sure that the top items are the most important ones.

**Sprint Planning**

* Events done for <mark style="background-color:yellow;">crafting a sprint goal</mark>, and for the developers to <mark style="background-color:yellow;">select the Product Backlog items</mark> to be developed during the Sprint.
* The sprint goal and the selected items form the [#sprint-backlog](#sprint-backlog "mention").

**Sprint Backlog**

* Also <mark style="background-color:yellow;">contains an actionable plan</mark> for delivering an **Increment**.

**Sprint**

* During the Sprint which <mark style="background-color:yellow;">usually lasts at most one month</mark>, the developers conduct daily scrums to synchronize their work and maximize their chances of achieving the Sprint Goal.
* During the sprints, the moment a ***Product Backlog*** item meets the Definition of Done, an ***increment*** is born.

**Increment**

* <mark style="background-color:yellow;">Is a concrete stepping stone toward the</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">**product goal**</mark><mark style="background-color:yellow;">.</mark>
* At the end of each sprint the scrum team conducts two events.
* First they run a Sprint Review event in which the scrum team and the ***invited stakeholders*** inspect to produced increment, giving informed feedback that might adapt the ***product backlog***.
* Afterward the scrum team members run a Sprint Retrospective event, in which they inspect and adapt their interactions, processes, and the definition of done, which might impact the next sprint planning event.