artifacts

The Sprint Goal is one sentence – like a vision for the Sprint.

It is written by the Product Owner and needs to be accepted by the team.

During a Sprint there are no changes allowed that affect the goal of a Sprint.

Story Points are units to measure the complexity of a User Story.

It does not equal the time needed to complete the story.

This fact is important to ensure that the number of Story Points does not depend on the experience of the developer who will accomplish the story.

To define the Story Points of a User Story you can have a look on its characteristics/complecity, e.g.:

• number of layers affected in the architecture
• number of interactions needed (with designers, front-end developers, …)

The best thing is always to complare it to previous User Stories with a similar complexity and then define the Story Points.

A Product Increment is the outcome of an iteration (Sprint).

In SCRUM the most important question concerning a specific Product Increment is “What does done exactly mean?”.

The Increment is the set of all items of the Product Backlog which have been completed in a Sprint.

The Sprint ends with an Increment which is in useable condition and meets the Definition of “Done”.

Each Increment will be thoroughly tested, ensuring that the product will work after release.

It must be in useable condition regardless of whether the Product Owner decides to actually release it.

User Stories are the State-of-the-Art way to describe requirements in the Product Backlog.

They should not have a technical focus, but focus on the users/customers needs.

User Stories must be easy to understand for everyone in the team as well as for stakeholders.

You normally write a User Story in one sentence build in the following format:

1. As a user/guest/member/admin/… [actor]
2. I want … [action]
3. so that … [achievement]

So WHO wants WHAT and WHY.

Size

A perfect size of a user story is a story that can be implemented within 1-3 days.

Acceptance Criteria

Every User Story needs a defined Acceptance Criteria.

When you use cards, you can simply write the User Story on the front side and the Acceptance Criteria on the Backside.

INVEST Priciple for GOOD User Stories

• Independent (I)
  is not depending on another User Story
• Negotiable (N)
  is a basis for collaborative refinement
• Valuable (V)
  is valueable for users, customers or contracting authorities
• Estimatable (E)
  has an estimatable effort (by Developement Team through Story Points)
• Small (S)
  is small enough that you don’t need to split it further
• Testable (T)
  can be tested

Splitting in tasks

The Development Team estimates the time needed to implement the User Story within a Sprint. They also derivate several technical tasks for each story.

Epics

Big user stories that still need to be decomposed are epics and groups of related stories can be bundled in epics.

User Story Maps

A story map is a construct where epics are placed next to each other and the related stories are below, ordered by priority.

A Burn up Chart shows the number of issues accomplished (y-axis) within the sprint (time, x-axis).

This is the most popular way to track the progress of a SCRUM project.

The Burn down Chart shows the number of issues per day that are NOT done (y-axis) within a time – the current sprint timebox, e.g. 4 weeks (x-axis).

The vertical axis always shows the amount of work.

There are two different types of Burn down Charts:

• Sprint Burn down Chart
  The Sprint Burn down Chart shows the progress for the duration of the respective Sprint.
  
• Release Burn down Chart
  The Release Burn down Chart shows the progress of Product Backlog items / features. Here te x-axis shows the number of Sprints. The SCRUM Master updates the Release Burn down Chart at the end of each Sprint.

Example

We have 80 things to create.

And as the Developement Team starts accomplishing these different stories we reduce (burn down) the number of items we have to create.

The Sprint Backlog is a selected subset of the Product Backlog.

It contains the stories selected to be accomplished within this Sprint.

The Selection takes place in the Sprint Planning Meeting.

Based in that the Developement Team derives tasks for each User Story and assigns it to a developer.

All work of the Development Team within a Sprint is based on the Sprint Backlog.

The Development Team is responsible for the accomplishment of the Sprint Backlogs’ items.

The Product Backlog (PBL) is owned by the product owner and shows what needs to be done.

It is a prioritized set of high-level requirements to the product (descending by value for the users).

These requirements are called features or User Stories of just stories. The list can also contain Bugs. It can have a technical nature, but in best case it is user-centric.

Ideally each item should have value for the user.

All work of the Development Team is based on the Product Backlog.

The Product Backlog is a dynamic document, which is updated constantly by the Product Owner.

This updating is called Backlog Grooming. The prioritization of the items in the Product Backlog is an also important part of the Grooming.

The Product Backlog is never complete or done. It contains the known and best understood requirements.

Prioritization of User Stories

One method to prioritze stories is “Wieger’s prioritization technique”:

Prio = (value in %) / ((cost in % * cost weight) + (risk in % * risk weight))