# Noter til Scum - BSUP
###### tags: `BSUP`, `Scrum`

## Scrum
### Scrum in 100 words (before 2020)
>• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize
to determine the best way to deliver the highest
priority features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.

### Characteristics
* Self-managing team
* Value is generated in a series of “sprints” of fixed length of one month or less
* Requirements are captured as items in an artifact known as the “product backlog”
* … an emergent, ordered list of what is needed to improve the product.
* No specific engineering practices are prescribed. It is a general purpose project management framework
* Fairly simple. It uses generative rules to create an agile environment for delivering projects
* One of the “agile processes”

### Characteristics

## The Agile Manifesto a statement of values
**Individuals and interactions** over **Process and tools**

**Working software** over **Comprehensive documentation**

**Customer collaboration** over **Contract negotiation**

**Responding to change** over **Following a plan**

> You should know the manifesto for the exam

## Scrum framework

* Team
* Events
* Artifacts


> ### **Scrum - A practical example**
> 

### Team
* Product owner
* Scrum master
* Developers

#### Product Owner
* Accountable for maximizing the value of the product resulting from the work of the scrum team.
* Accountable for effective product backlog management.
* Developing and explicitly communicating the product goal.
* Creating and clearly communicating Product Backlog items.
* Ordering Product Backlog items.
* Ensuring that the Product Backlog is transparent, visible, and understood.
* The product owner may do the above work or may delegate the responsibility to others.
* The product owner is one person, not a committee.
* Scope/schedule tradeoff decisions: decide on release date and content.
* Be responsible for the profitability of the product (ROI).

#### The Scrum Master
* Accountable for establishing Scrum as defined in the scrum guide.
* Serves the scrum team in several ways, including:
* Coaching the team members in self-management and cross-functionality;
* Helping focus on creating high-value Increments that meet the Definition of Done;
* Causing the removal of impediments to progress; and,
* Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
* The Scrum Master serves the Product Owner in several ways, including:
* Helping find techniques for effective Product Goal definition and Product Backlog management;
* Helping the Scrum Team understand the need for clear and concise Product Backlog items;
* Helping establish empirical product planning for a complex environment; and,
* Facilitating stakeholder collaboration as requested or needed.
* The Scrum Master serves the organization in several ways, including:
* Leading, training, and coaching the organization in its Scrum adoption;
* Planning and advising Scrum implementations within the organization;
* Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
* Removing barriers between stakeholders and Scrum Teams.

#### The Developers
* Committed to creating any aspect of a usable Increment each Sprint.
* Typically 5-9 people
* Accountable for:
* Creating a plan for the Sprint, the sprint backlog;
* Instilling quality by adhering to a definition of done;
* Adapting their plan each day toward the sprint goal; and,
* Holding each other accountable as professionals.
* Cross-functional:
* Programmers, testers, user experience designers, etc.
* Everyone needed to deliver the increments
* Members should be full-time
* May be exceptions (e.g., database administrator)
* Teams are self-managing
* Ideally, no titles, but rarely a possibility
* Membership should change only between sprints

### Events
* Sprint
* Sprint planning
* Sprint review
* Spring retrospective
* Daily scrum

#### Sprint
* Scrum projects make progress in a series of “sprints”.
* Typical duration is of one month or less.
* Fixed duration: a constant duration leads to a better rhythm.
* Product is designed, coded, and tested.
* No changes are made that would endanger the Sprint Goal.
* A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the product owner has the authority to cancel the sprint.

> **Sequential versus overlapping
development**
> 

> **No changes during a sprint**
> 
> * Plan sprint durations around how long you can commit to keeping change out of
the sprint

#### Sprint planning event

* Topic One: Why is this Sprint valuable?
* The Product Owner proposes how the product could increase its value and utility in the current Sprint.
* Topic Two: What can be Done this Sprint?
* Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
* Topic Three: How will the chosen work get done?
* For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the
* Definition of Done.
* Time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

##### Sprint planning event - a partial example

* The developers select items from the product backlog they can commit to completing
* Sprint backlog is created
* Usually, sub-tasks are identified and each estimated (1-16 hours)
* Collaboratively, not done alone by the ScrumMaster
* High-level design is considered

#### Sprint planning event
* Purpose
* Inspect progress toward the Sprint Goal
* Adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
* Parameters
* Daily
* 15-minutes maximum
* (Stand-up)
* Participants
* Developers
* If the product owner or scrum master are actively working on items in the sprint backlog, they participate as developers.
* Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings

##### A common framework
1. What did you do yesterday?
2. What will you do today?
3. Is anything in your way?

- These are not status for the scrum master or the product owner
- They are commitments in front of peers
- They are synchronization meetings
- Not for problem solving
- Event for the developers to adjust upcoming planned work, if necessary.

#### Sprint review event
* Inspect&Adapt on the product
* Purpose
* Inspect the outcome of the sprint and determine future adaptations.
* The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed
* Invite the world
* Time-boxed to a maximum of four hours for a * one-month Sprint. For shorter Sprints, the event is usually shorter.

#### Sprint retrospective event
* Inspect&Adapt on the process
* Purpose
* Inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their definition of done
* Improvements may even be added to the sprint backlog for the next Sprint.
* Time-boxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

##### A common framework
Whole team gathers and discuss what they'd like to:
- Start doing
- Stop doing
- Continue doing

>This is just one of many ways to do a sprint retrospective

### Artifacts
* Product backlog
* Sprint backlog
* Increment

#### The product backlog
* The requirements
* Emergent, ordered list of what is needed to improve the product
* Ideally expressed such that each item has value to the users or customers of the product
* Prioritized by the product owner
* Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items
* The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

##### A sample product backlog

##### A sample product backlog
* Future state of the product, which can serve as a target for the Scrum Team to plan against.
* Long-term objective for the Scrum Team.
* Must be fulfilled (or abandoned) before taking on the next

#### The Sprint backlog

* Composed of why, what, how.
* A plan by and for the Developers.
* Highly visible, real-time picture of the work that the
* Developers plan to accomplish during the Sprint to achieve the Sprint Goal.
* Updated throughout the Sprint as more is learned
* Enough detail that they can inspect their progress in the Daily Scrum

##### Commitment: The Sprint goal

* A short statement of what the work will be focused on during the sprint.
* Commitment by the developers.
* Encourages to work together rather than on separate initiatives.
* If the work turns out to be different than they expected, developers collaborate with the product owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

#### Increment
* A concrete stepping stone toward the Product Goal.
* Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
* Multiple Increments may be created within a Sprint.
* The sum of the Increments is presented at the Sprint Review thus supporting empiricism.
* An Increment may be delivered to stakeholders prior to the end of the Sprint.
* The Sprint Review should never be considered a gate to releasing value.

- Managing the sprint backlog
- Making work visible
- The burn down chart
- The burn up chart

##### Commitment: The definition of done


* A formal description of the state of the Increment when it meets the quality measures required for the product.
* The moment a Product Backlog item meets the Definition of Done, an Increment is born.
* If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.
* The Developers are required to conform to the Definition of Done.

### Managing the sprint backlog
* Individuals sign up for work of their own choosing
* Work is never assigned
* Estimated work remaining is updated daily
- Any team member can add, delete, or change the sprint backlog
- *Work for the sprint emerges*
- If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
- Update work remaining as more becomes known

#### A Sample sprint backlog - An example

#### Making work visible

Bottom one = Burn Up Chart, see the work done, per sprint
Top one, one missing to be done