# Noter til User stories - BSUP
###### tags: `BSUP`, `User stories`

## User stories

### What problem do stories address?
- Software requirements is a communication problem
- Those who want the software must communicate with those who will build it

### Balance is critical
- If either side dominates, the business looses
- If the business side dominates …
- … functionality and dates are mandated with little regard for reality whether the developers understand the requirements
- “I need this, I need it by this date, make it happen”
- If the developers dominate …
- … technical jargon replaces the language of the business and developers lose the opportunity to learn from listening
- “we will build whatever you want, but you have to fill out this complicated usecase template. Fill this out and that will tell us what to build for you. If you do not fill this out, we will not build you the right thing”


### Resource allocation
- We need a way of working together so that resource allocation becomes a shared problem
- Project fails when the problem of resource allocation falls too far from one side

#### Responsibility for resouce allocation
* If the developers responsible …
* … may trade quality for additional features
* … may only partially implement a feature
* … may solely make decisions that should involve the business
* If the business is responsible …
* … lengthy upfront requirements negotiation
* … features are progressively dropped when the deadline nears

### Imperfect schedules
* We cannot perfectly predict a software schedule
* As users see the software, they come up with new ideas
* Too many intangibles
* Developers have a notoriously hard time estimating
* If we can’t perfectly predict a schedule, we can’t perfectly say what will be delivered

### So what do we do?
- We make decisions based on the information we have **... but do it often**
- Rather then making one all-encompassing set of decisions **... we spread decision-making acriss the project**

**--> This is where user stories come in**

## What stories are
- just covered

## Writing user stories
> Good to make on paper
> Good to have colors
> Good to make in person within the group --> FASTEST

>**Example:**
>

### The three Cs

#### Samples from a travel website

##### Where are the details?
* Does the user get a full or partial refund?
* Is that refund to get credit card or is it site credit?
* How far ahead must the reservation be cancelled?
* Is that the same for all hotels?
* For all site visitors? Can frequent travelers cancel later?
* Is a confirmation provided to the user?
* How?

#### Details as conditions of satisfaction
- The product owner's conditions of satisfaction can be added to a story
- There are essentially tests

##### Details added in smaller sub-stories

### Techniques can be combined
- These approaches are not mutually exclusive
- Write stories at an appropriate level
- By the time it's implmented, each story will have conditions of satisfactions associated with it

### The project backlog iceberg

#### Some additional useful terms

##### An example

### INVEST in Good Stories

### Story writing workshops
* Includes whole team plus possibly some external stakeholders
* Typically not done every sprint
* Brainstorm to generate stories
* Goal is to write as many stories as possible
* Some will be “implementation ready”
* Others will be epics
* No prioritization at this point

### Start with epics and iterate

## Why user stories
- Shift focus from writing to talking

### Examples


### Words are imprecise

### Additional reasons
* Stories are understandable
* Developers and customers understand them
* People are better able to remember events if they are organised into stories
* Support and encourage iterative development
* Can easily start with epics and disaggregate closer to development time
* Stories are the right size for planning
* Stories support opportunistic development
* We design solutions by moving opportunistically between top-down and bottom-up approaches
* Stories support participatory design

#### Example: specifications IEEE-830-style
> Where is your head going?
* The product shall have a steel body
* The product shall have four wheels
* The product shall have a rubber tier mounted to each wheel
* The product shall have a multi speed transmission

### MOST IMPORTANTLY!