# Scrum Framework

We use the scrum framework to deliver core product value as often as possible.

## Essentials

We run a sprint of either two or four weeks:

* We set a goal (what we’re trying to optimize) and estimate the work to be done in a _Planning meeting_.
* Each day in the sprint, we discuss dependencies and impediments in a _Daily meeting._
* At the end of the sprint we review the new state of the product (aka _Increment_) in a _Review meeting_ and we review our process in a _Retrospective meeting_.

We have the following roles:

* _[Product Owner](/ZPqTbE6dS-alABmChRzOtg)_: Responsible for the business value of the product delivered by Development Team effort.
* _Development Team_: responsible for doing the work to move the product to the next increment.
* _Scrum Master_: responsible for helping everyone run the process.

## More Specifics

* It’s important to insist on strong user stories that are about _customer_ value — not internal value. Internal value goes into operations’ todo list. If your user stories are strong they literally rewire the team to focus on what the customer needs, as opposed to what each individual thinks is important.
* Estimate stories in half-day units, using the Fibonacci numbers: 1,2,3,5. Less than 1 unit doesn't qualify; over 5 units is too big for a story. This is important because it forces the team to think in enough detail to execute.
* Bugs are fixed as they are found, regardless of the sprint. If a bug is greater than 2 units, add it to a story for the next sprint.
* We maintain Product Backlog (prioritize user stories). The output of the Review Meeting should improve the Product Backlog. The output of the Retrospective should improve the Scrum process itself. These are recursive:


## Meetings

Here’s some basic information about how we run meetings.

### Planning

_(4 hours max)_

* Product Owner starts by explaining the goal of the sprint.
* Product Owner explains the user stories to the Development Team.
* The Development Team suggests ways to improve the stories. (They are not “fixed in stone”.)
* The Development Team then votes on how much effort they will spend on finishing the story. The unit of estimation is 1 (half day), 2, 3, 5.
* Everyone has to vote.
* If there is no obvious consensus, the larger estimator tries to convince the smaller one why extra time is necessary.
* If not convinced, we go with the longer estimate and learn.
* If the effort to finish a story is unexpected, unacceptable to the Product Owner, they work with the team to reduce / change the scope.

### Daily

_(15 minutes max)_

* Each person answers 3 questions:
* What did I do yesterday to help reach the sprint goal?
* What will I do today to help reach the sprint goal?
* What impediment do I see that might stop us from reaching the sprint goal?
* Scrum master stops potential long discussions; asks for people to meet after the meeting to solve it.

### Review

_(2 hours max)_

* The Development Team demos all stories to the Product Owner and relevant stakeholders.
* The Product Owner gives feedback on what has been implemented, and makes the decision on what to release.
* Product Owner then considers changes for Product Backlog.

### Retrospective

_(1.5 hours max)_

* Scrum Master, with the help from everybody, summarizes the important events and decisions made during the sprint.
* Together, everyone answers the following questions:
* What would they do the same?
* What they would do differently and what different result would they want to achieve?
* Everyone then votes on 3 improvements to make in the next sprint

## Final Thoughts

* It is really easy to ruin the creativity and performance by too much organization, rules and process.
* Keeping teams small helps to achieving a good balance of creativity and systems engineering for agility and affordability. Moving from 3 developers to 4 doubles the number of lines of communication:


* To scale, start to build a network of integrators spread through the company that pull together the work of various teams.

###### tags: `Engineering`