# Scrum Artifacts

## About

Scrum Artifacts can be examined frequently, but it should not get in the way of the work.

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.

## Product Goal ⭐

Its is <mark style="background-color:yellow;">contained within the product backlog</mark>.\ <mark style="background-color:yellow;">The PO is responsible for developing and explicitly communicating the product goal.</mark>\ <mark style="background-color:yellow;">It describes a future state of the product</mark>, which can serve as a target for the scrum team to plan against.\ <mark style="background-color:yellow;">It is the long term objective for the scrum team.</mark>

* The team might need multiple Sprints to fulfill it.

What fulfills the product goal?\
What do we need to do to get there?\
\&#xNAN;***the rest of the product backlog***

The product itself cannot be the goal.

> A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical products, or something more abstract.

You can have MULTIPLE products goals.

* <mark style="background-color:yellow;">**BUT the Scrum Team must ONLY focus on ONE product goal at a time.**</mark>
* Before moving on the next, the current one must be fulfilled or abandoned.
* Multiple scrum teams should also SHARE the same product goal.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FJ1icF0hWeiyAtHsYO3jG%2Fproduct-goal.png?alt=media&#x26;token=1e60a2b6-2730-43bd-99d6-d6d2d56ce61f" alt=""><figcaption></figcaption></figure>

### Product Vision

* This is where we define the boundaries for our product.
* Such as defining a value proposition and identifying the key stakeholders and users or customers.
* It makes a link between the product and the business strategy.
* ***The Scrum Guide does not cover much of it.***

### Product Strategy

* Is where we define how the vision will be realized.
* ***This is where the PRODUCT GOALS come in.***
* <mark style="background-color:yellow;">Part of the product strategy is to define the product goals.</mark>
  * They are manifestations of the product strategy, a measurable direction towards the product vision.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FAafwpt8607FrQ6WkG0IW%2Fproduct-strategy.png?alt=media&#x26;token=b1cdf64d-12b1-46bf-ab42-251c69050ef5" alt=""><figcaption></figcaption></figure>

## Product Backlog ⭐

<mark style="background-color:yellow;">The Product Backlog commits to the Product Goal.</mark>

As long as a Product exists, its Product Backlog also exists.

An <mark style="background-color:yellow;">emergent, ordered</mark> list of what is needed to improve the product.

* What is needed:
  * <mark style="background-color:yellow;">Means that the product backlog is the single source of work for the scrum team.</mark>
  * It lists all:
    * Features, Functions, Requirements, Enhancements, and Fixes,
    * that constitute the changes to be made to the product in future releases.
* Emergent:
  * The product log follows what we call ***just-in-time*** requirements.
    * <mark style="background-color:yellow;">Meaning that we only detail enough items ready for the up coming Sprint.</mark>
    * <mark style="background-color:yellow;">A product backlog item can be considered</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">**READY**</mark><mark style="background-color:yellow;">, when it can be done within one Sprint.</mark>
      * But Ready is not a gate.
    * And why Scrum follows this practice?
      * Because we expect things to change.
      * And detailing everything becomes WASTE.

A product has ONE product backlog, no exceptions.

Ordering the Product Backlog is a Critical activity.

**Product Backlog must be DEEP:**

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Detailed</strong></td><td><ul><li>Consider dependencies.</li></ul></td><td></td></tr><tr><td><strong>Estimated</strong></td><td><ul><li>Insurance against risks.</li></ul></td><td></td></tr><tr><td><strong>Emergent (It Evolves)</strong></td><td><ul><li>Value, could be inferred with <code>Kano</code> for instance.</li></ul></td><td></td></tr><tr><td><strong>(P)Ordered</strong></td><td><ul><li>Estimated effort, using <code>Story Points</code>.</li></ul></td><td></td></tr></tbody></table>

**So considering this, INVEST on your Product Backlog wisely:**

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>(I)ndependent</strong></td><td><ul><li>Should aim for having independent items.</li></ul></td><td></td></tr><tr><td><strong>(N)egotiable</strong></td><td><ul><li>The items must be a result of a conversation between business and dev.</li></ul></td><td></td></tr><tr><td><strong>(V)aluable</strong></td><td><ul><li>Must have business value.</li></ul></td><td></td></tr><tr><td><strong>(E)stimatable</strong></td><td><ul><li>Must have enough information or the team have enough knowledge to estimate the effort to deliver it.</li><li><p>If this cannot be done, you can apply a technique called <em><strong>SPIKE</strong></em>.</p><ul><li>Where part of the team capacity is reserved to explore an item to the point they are now able to estimate it.</li></ul></li></ul></td><td></td></tr><tr><td><strong>(S)mall</strong></td><td><ul><li>Must be small enough (<strong>just-in-time</strong>), to ease planning and ordering, and so it can fit a Sprint.</li></ul></td><td></td></tr><tr><td><strong>(T)estable</strong></td><td><ul><li>The team must be able to verify if it is done.</li><li>Acceptance criteria. (From User Stories)</li></ul></td><td></td></tr></tbody></table>

**What does the product backlog details:**

The attributes vary with the domain of work and COULD be:

* A description,
* Order,
* and Size.

Usually a healthy product backlog is like this:

* <mark style="background-color:yellow;">Small part of it ready for Sprint</mark>,
  * These are the more clear, detailed items, that are higher ordered.
  * The more important stuff, that the team will focus.
* <mark style="background-color:yellow;">The rest are unrefined items</mark>, and are not detailed, following the practice of ***just-in-time***.

### Product backlog (Description)

Can be divided in 3 categories, before it is ready to be considered a feasible item.

#### **The LARGE SIZE and LOW DETAILED items (EPIC):**

* Called <mark style="background-color:yellow;">EPICs</mark>.
* Are <mark style="background-color:yellow;">briefly described product features</mark>.
* They are too large to fit a Sprint.
* They are the <mark style="background-color:yellow;">abstract things that need to be done</mark>, but weren't yet refined.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FUWg3icm9WCwIAI39chdf%2Fepics.png?alt=media&#x26;token=c80df395-6c8a-4480-9bb8-713609307c27" alt=""><figcaption></figcaption></figure>

#### **The SMALL SIZE and HIGH DETAILED items:**

These small refined ones usually are:

User Stories:

* Have three components:
  * <mark style="background-color:yellow;">Card</mark>
    * Is a <mark style="background-color:yellow;">written description</mark> of the functionality that will be valuable to either a user or a customer.
    * So it is <mark style="background-color:yellow;">written from the perspective of a customer or user</mark>.
  * <mark style="background-color:yellow;">Conversation</mark>
    * Represents the collaboration between the PO, the business people, and the technical people.
  * <mark style="background-color:yellow;">Confirmation</mark>
    * A <mark style="background-color:yellow;">list of criteria that the Scrum Team, will defined to serve as a verification</mark>, if the product delivered suits the needs.
* The most popular notion of a User Story **description** is:
  * As an \[actor] (actor: the User, the Customer)
  * I want \[action] (action: Something that the actor wants, or needs to do)
  * so \[end] (end: It is important to know the motivation for the user to want to do something, so the team can find the best way to attend to his needs)
    * Good exemples:
      * \[e-commerce]: As a sales manager I want to generate a monthly sales report so that I can verify if the teams goals were fulfilled.
      * \[airbnb]: As a rentant I want to reserve an apartment online to ease my vacation planning.
      * \[proj4me]: Team member can visualize his/her current task to be aware of his/her to-do list.
    * Bad exemples:
      * The houses project will be in autocad.
      * The software will be written in C.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FWv0Dt6pTjr6naRnCrStl%2Fuser-story.png?alt=media&#x26;token=88186a32-c47d-4ded-a330-1b7ff525ff7d" alt=""><figcaption></figcaption></figure>

### Product backlog (Order)

4 factors for ordering the product backlog items.

* <mark style="background-color:yellow;">Size</mark> (Story Unit - Planning Poker)
* <mark style="background-color:yellow;">Risk</mark>
* <mark style="background-color:yellow;">Value</mark> (Business Value) (Very context dependent) (Kano Model)
* <mark style="background-color:yellow;">Dependencies</mark>

Lets order some backlog items considering the Business Value:

| User Story |  BV | Order |
| ---------- | :-: | ----: |
| 1          |  10 |     2 |
| 2          |  12 |     1 |
| 3          |  6  |     3 |
| 4          |  5  |     4 |
| 5          |  4  |     5 |

But we could make it better and also consider its Size, and maybe order it by ROI (Return on Investment)

\
$$ROI = \frac{Business\ Value}{Size}$$

| User Story |  BV | Size | ROI | Order |
| ---------- | :-: | :--: | :-: | ----: |
| 1          |  10 |   5  |  2  |     2 |
| 2          |  12 |  10  | 1.2 |     4 |
| 3          |  6  |   3  |  2  |     3 |
| 4          |  4  |   2  | 2.5 |     1 |
| 5          |  5  |   5  | 0.8 |     5 |

But maybe ordering it like this could not be possible due to a Technical or Business Dependency. We always try to avoid having dependent product backlog items, but sometimes its just too hard to fulfill this.

Ex.:

> How can the user Sign-in to the system if he can't Sign-up.\
> Sign-up would have to come firs as a technical dependency.

So lets say that User Story 1 depends on the User Story 2:

| User Story |  BV | Size | ROI | Order | New Order |
| ---------- | :-: | :--: | :-: | ----: | --------: |
| 1          |  10 |   5  |  2  |     2 |         4 |
| 2          |  12 |  10  | 1.2 |     4 |         3 |
| 3          |  6  |   3  |  2  |     3 |         2 |
| 4          |  4  |   2  | 2.5 |     1 |         1 |
| 5          |  5  |   5  | 0.8 |     5 |         5 |

> User story 3 goes before 1 now because they have the same ROI, but 3 does not depend on no one.

Now for the Risk. For instance, suppose that you are developing a augmented reality app. The augmented reality is what makes the product stands out, and your company never worked with it before.\
Independent of the other factors, you might want to put the product backlog items related to augmented reality on the top.

Because if, for instance, the programming language or framework that you are planning to use does not support it, you will want to know that before wasting time developing other features.

### Product backlog <mark style="background-color:yellow;">(sizing/size) (estimation)</mark>

In agile a '<mark style="background-color:yellow;">lightweight</mark>' approach is taken for estimating the time it will take for doing the work.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FmitP39eR8n7a5rCe8JG8%2Fbacklog-estimation.png?alt=media&#x26;token=0cd79935-38d6-486d-86de-f77589ba1de0" alt=""><figcaption></figcaption></figure>

<mark style="background-color:yellow;">Scrum does not prescribe any rules about estimates.</mark>

The most popular measure unit is the Story Point. Which is an Agile alternative to hours/days.

And the most used estimation technique is the Planning Poker.

#### <mark style="background-color:yellow;">**Story Point**</mark>**&#x20;(Measure Unit)**

In agile it is not recommended to estimate work units in time, because it generates a lot of effort. And you will end up with inaccurate estimates anyways.

Even thou management WILL ask for estimation in TIME, the ideia is to <mark style="background-color:yellow;">use relative sizing</mark>.

For instance, assume we have a pool of `25m`, and it is asked how long it would take to swim across it.\
Times would be different depending on the person. So the approach is to think of the swimming pool length as relative size considering other lengths like `50m`, `75m` and etc.

So this `25m` one would be of length `1`, the `50m` would be `2`, and so on.\
This is relative size thinking.

The story points use the semi-fibonacci scale.

$$0 \rightarrow 1 \rightarrow 2 \rightarrow 3 \rightarrow 5 \rightarrow 8 \rightarrow 13 \rightarrow 20 \rightarrow 40 \rightarrow 100...$$

*Up to 13, the values are calculated by adding the two last ones:* $(2 + 3 = 5)$, $(5 + 8 = 13)$\
\&#xNAN;*After 13 it is arbitrary since, we humans often fail to estimate big things.*

In Agile we don't estimate thinking about having me or you doing the task, is is about the team.

<mark style="background-color:yellow;">It is a</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">**TEAM METRIC**</mark>.

***But you can never compare teams productivity using Story Points.***

#### <mark style="background-color:yellow;">**Planning Poker**</mark>

Is an <mark style="background-color:yellow;">estimation technique</mark>.\
Is a <mark style="background-color:yellow;">collaborative consensus based agile estimating technique</mark>, in which each developer holds a deck of cards containing the numbers we just discussed, having each number, represent a story point.

Then the PO is going to read a product backlog item, developers discuss that item: to know the size, the complexity, that do they need to do, the risks involved for developing it.

After, each developer privately selects one card to represent his estimate.

So if our estimators selected the same value, that becomes the estimated value. If not they discuss their estimates, and then go on another round, until consensus is reached.

**Tips on starting a planning from 0**:\ <mark style="background-color:yellow;">You will get the easiest backlog item (User Story), the one that could be done in a few days, and give it a</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">`2`</mark><mark style="background-color:yellow;">.</mark>

After that, you estimate the remaining ones in comparison to that one and that's it.

<mark style="background-color:yellow;">Notice that these estimates depend on the Definition of Done.</mark>

***So the more rigorous are the criteria to have a Done increment, in terms of, quality and documentation, the more costly it is to develop it*****.**

### Product backlog <mark style="background-color:yellow;">(value / business value)</mark>

<mark style="background-color:yellow;">Scrum does not prescribe any techniques for this purpose.</mark>

#### <mark style="background-color:yellow;">**The Kano model**</mark>

It is based on <mark style="background-color:yellow;">classifying items into one of three categories</mark>:

* <mark style="background-color:yellow;">Mandatory</mark>
  * It is about things that if your product has the customer won't care a lot, but if it doesn't have, they will hate it.
  * <mark style="background-color:yellow;">All theses features, MUST be included in the Backlog.</mark>
* <mark style="background-color:yellow;">Linear</mark>
  * Are features that the more you have, the more you can charge the customer.
  * <mark style="background-color:yellow;">Backlog must include as many as possible.</mark>
* <mark style="background-color:yellow;">Exciter</mark>
  * It is about unknown desires.
  * The customer wont be upset if you don't deliver it, because they don't even know they want it.
  * But if you do deliver, its the thing that makes it stand out.
  * <mark style="background-color:yellow;">You should leave a little room for you exciters.</mark>

So, for each backlog item ask two things to users or customers:

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2F7IpGEer8lZ23NbbA8cy5%2Fkano-classify.png?alt=media&#x26;token=c1415873-a0c5-4949-8bfc-cdd66ea32d7a" alt=""><figcaption></figcaption></figure>

* One question on the Function form.
* The other in Dysfunction form.

After the data gather, analyse it:

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FXVjfBuUybBVPJHzbVnJO%2Fkano-questions.png?alt=media&#x26;token=e5ebd9d4-06b3-4337-a657-f34b99c377ec" alt=""><figcaption></figcaption></figure>

* Mandatory feature:
  * Functional: 'Expect', 'Are Neutral' or 'Live with it'.
  * Dysfunctional: 'Dislike'.
* Linear feature:
  * Functional: 'Like'.
  * Dysfunctional: 'Dislike'.
* Exciter feature:
  * Functional: 'Like'.
  * Dysfunctional: 'Except', 'Neutral', 'Lives'.

### Product backlog <mark style="background-color:yellow;">(Refinement)</mark>

<mark style="background-color:yellow;">It is the act of breaking down and further defining product backlog items into smaller more precise items.</mark>

The ordering of Product Backlog items is also considered a Refinement.

Usually, it <mark style="background-color:yellow;">is what enables getting the backlog items Ready</mark>.

<mark style="background-color:yellow;">But it is ok for the team to try implement a backlog item that is not 100% Ready.</mark>

The scrum team decides how and when refinement is done.

#### **The&#x20;**<mark style="background-color:red;">**Definition of Ready**</mark>**&#x20;⭐**

<mark style="background-color:yellow;">Is not and official Scrum Guide practice.</mark>

It is a <mark style="background-color:yellow;">set of criteria that defines when a product backlog item is ready to be executed</mark>. Usually we have at least these criteria:

* Acceptance criteria defined.
* Team understands what has to be done.
* <mark style="background-color:yellow;">Fits a Sprint.</mark>

## Monitoring progress toward Goals ⭐

<mark style="background-color:yellow;">Should be inspected frequently and diligently to detect potentially undesirable variances or problems.</mark>

### **Burn-Down**

The ideia is to burn, from top to the bottom, the work to be done to reach a goal.\
Usually the goal is to deliver the product backlog.

So you will add up all the estimate points, using for instance Story Points, for all the backlog items. And update a chart like these after each Sprint.

Lets also assume that there is a Goal to reach at Sprint 8.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2F8Ib7tRtRP1yr6D19NUv0%2Fburndown.png?alt=media&#x26;token=08047e8c-caf2-4093-8650-68e4df52f1b1" alt="" width="563"><figcaption></figcaption></figure>

So the read line, would be a linear estimation from the beginning to the Goal.\
And after each sprint, you would set the remaining points to be done.\
If your line is above the estimation, 'You are Late'.\
If your line is bellow the estimation, 'You are on Time'.

***The problem with this approach, is that the product backlog, is a living artifact, and it changes with the Sprints.***

***So the Burn-down is not really good to show these modifications.***

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2F4a4RXuO8hAohyLva88nm%2Fburndown-2.png?alt=media&#x26;token=73651778-8cf4-496b-96d6-de6dd22ebc21" alt=""><figcaption></figcaption></figure>

In this example, it might seem that the team did not burn any points during the Sprint, but they could have burn 10 points, and due to change in the backlog, more user stories were added, and so more points were added again.

It would be even worse, if more points were added than burned.

### **Burn-Up**

It is similar to the Burn-down, but instead of going top to bottom, we go from bottom to up.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FbuGVLGw1wLPcHiouT0VI%2Fburnup.png?alt=media&#x26;token=ba6d6ff0-cd7b-4de5-a6f2-32828e78271d" alt=""><figcaption></figcaption></figure>

The catch is that, the Blue line represents the work DONE/POINTS BURNED by the team.

And the Red line represents the work to be Done. This line can either stay horizontal if nothing is added to the Backlog, or can go up, representing more work added to be done.

### **Cumulative Flow**

While the Burn-Up chart show progress towards a goal, the cumulative flow diagram shows the distribution of all product backlog items across various states over time.

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FrXPZpG1byKu5zrexjGnd%2Fcumulative-flow.png?alt=media&#x26;token=317d4966-2330-41e0-9a54-1ed9ad72dcad" alt=""><figcaption></figcaption></figure>

## The Increment ⭐

<mark style="background-color:yellow;">The increment commits to the Definition of Done.</mark>

The Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

It is developed during Sprints, and it is cumulative.\
In other words, <mark style="background-color:yellow;">for the first Sprint, the Increment is the sum of all the backlog items completed</mark>.

<mark style="background-color:yellow;">For the second one, the Increment is a sum of all the backlog items during the Sprint and the value delivered of all previous Sprints.</mark>

<mark style="background-color:yellow;">But since when a backlog item meets the Definition of Done, a Increment is born, multiple Increments may be created within a Sprint.</mark>

<mark style="background-color:yellow;">However, the sum of such Increments is presented a the Sprint Review.</mark>

The Increment is KEY for successfully driving changes in Scrum.

The feedback on the Increment will drive the Scrum Team into optimizing the delivered value. And this is why we say that the Increments supports empiricism.

* <mark style="background-color:yellow;">You DO NOT need make a</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">**Release**</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">at the end of every Sprint.</mark>
  * <mark style="background-color:yellow;">The Scrum Team can make the</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">**Release**</mark> <mark style="background-color:yellow;"></mark><mark style="background-color:yellow;">whenever it feels like it is valuable.</mark>
* The Sprint is NOT A GATE, Releases might be performed during a Sprint.

### <mark style="background-color:red;">The Definition of Done</mark> ⭐

Defines what is needed for work to be considered done.

> A formal description of the state of the Increment when it meets the quality measures requered for the product.

<mark style="background-color:yellow;">The moment a backlog item meets the Definition of Done, an Increment is born.</mark>

<mark style="background-color:yellow;">If a backlog item does not meets the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the backlog for future consideration.</mark>

$$
Done\ items = Usable\ for\ end\ users = Potentially\ shippable = Potentially\ releasable
$$

Such criteria might be:

> Quality assurance\
> Architecture\
> Non-functional requirements\
> Process Management\
> Configuration management

$$
Definition\ of\ Done \neq Acceptance\ Criteria\ (from\ User\ Story)
$$

<mark style="background-color:yellow;">Acceptance Criteria is specific for ONE User Story.</mark>

<mark style="background-color:yellow;">The Definition of Done, englobes all of them.</mark>

***It is strongly related to QUALITY.***

***Who defines the Definition of Done?***

* <mark style="background-color:yellow;">The organization, BUT, if it does not, then the Scrum Team MUST define one.</mark>

<mark style="background-color:yellow;">The Definition of Done, can be set by the Organization, if it requires standard quality or requirements.</mark>

<mark style="background-color:yellow;">The Scrum Team can than have these as minimal Definitions, and then add more if necessary.</mark>

<mark style="background-color:yellow;">Also two scrum teams, can have different Definitions of Done, BUT, since an Increment can ONLY HAVE ONE, these two team MUST have a MUTUAL set of common definitions, and then add to it.</mark>

<mark style="background-color:yellow;">The Definition of Done might evolve with time</mark>, and is expected to include more stringent criteria for higher quality. But it can also edit or remove criteria.

It can happen that by adding more criteria, the team will have to do more work in previous Done Increments.

The Definition of Done shouldn't change in the middle of the Sprint

### Technical Debts

<mark style="background-color:yellow;">It is not cited by the Scrum Guide.</mark>

It is consequences of poor software development practices.\
Might lead to code decay and architecture deterioration.

In summary, a code with high technical debt means that its really hard to work with and the cost of change is high.

It is not necessarily bad, but maybe it was just a part of the learning process.

## Sprint Backlog ⭐

<mark style="background-color:yellow;">The Sprint Backlog commits to the Sprint Goal.</mark>

<mark style="background-color:yellow;">The Developers commit to the Sprint Goal.</mark>

Is the OUTPUT of a Sprint Planning.\ <mark style="background-color:yellow;">The Sprint Backlog is Emergent, meaning that it can be UPDATED, during the Sprint.</mark>

<mark style="background-color:yellow;">Only the Developers are allowed to change the Sprint Backlog.</mark>

It is composed of:

* <mark style="background-color:yellow;">Sprint Goal (Why?)</mark>
* <mark style="background-color:yellow;">Selected PBI's (Product Backlog Items) (What?)</mark>
* <mark style="background-color:yellow;">Plan (How?)</mark>

<mark style="background-color:yellow;">The Sprint Goal NEVER changes, but the selected PBI's or the Plan can change.</mark>

<mark style="background-color:yellow;">The Sprint is not about delivering the selected PBI's, BUT ACHIEVING the Sprint Goal.</mark>
