Product Increment

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 Story

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.

Example

As a LinkedIn member I want to assign a different privacy level to different types of content parts so I can control who I share which information with.


Product Backlog Refinement

The Product Backlog is the collection of all product requirements.

The Product Owner is responsible for the Product Backlog, but for the Product Backlog Refinement he involves the Development Team to help him.

 

Attendees (who)

In the Product Backlog Refinement both, Product Owner and Developers work together in harmony.

 

 

When

The Product Backlog Refinement is done before the next Sprint Planning Meeting for a specific set of user stories.

 

Frequency

Every 1-2 weeks

 

Duration

1-1.5 hours


Burn up Chart

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


Burn down Chart

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.


Sprint Backlog

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.


Product Backlog

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))

Product Backlog SCRUM


Sprint Retrospective Meeting

Inspect & Adapt (what)

In this meeting we review the last Sprint, the Product Owners feedback he gave in the Sprint Review Meeting and we have a look at the last Retrospective Meeting:

  • Are there lessons learned?
  • Are there opportunities for improvement?

If necessary we create and assign issues with the approach to improve e.g. the process.

Attendees (who)

SCRUM Master

Product Owner

Developement Team

may be further stakeholders

 

When

After the Sprint Review Meeting and before the next Sprint Planning Meeting there will ba a Sprint Retrospective Meeting.

Details

It is an opportunity for the team to reflect on how well the Sprint operated for them and they are taken the advice from the Product Owner and the customers.


Sprint Review Meeting

In a Sprint Review Meeting the Development Team shows the finished work to the Product Owner (Demonstration).

Attendees (who)

When

At the end of each Sprint, the Scrum Master organizes a Sprint Review Meeting.

Details

The Development Team will show the Product Owner a demonstration (Demo) of the work they have done in the Sprint.

It is an opportunity for the Product Owner, the team and customers to talk about the sprint.

All together will decide of “done” has been achieved and the work is completed.

The Product Owner and the Development Team will discuss the Sprint and the items left in the Product Backlog.


Daily SCRUM Meeting

Defintion (what)

The Daily SCRUM Meeting is a 15 minutes timboxed meeting, always at the same location and time.

Participants (who)

Development Team

SCRUM Master as a facilitator

 

Agenda (how)

Every member of the Development Team answers these 3 questions:

  1. What did I do since the last Daily SCRUM?
  2. What will I do today?
  3. Are there any impediments in my way of getting things done?

If there are any impediments, the affected issues need to be marked.

Details

It usually takes place at the beginning of each working day. The SCRUM Master works as a facilitator and reminds the team to held the Daily SCRUM.

If there is a real-life task board (e.g. Kanban) and people work at the same location, then they can stand around it.

To ensure that the meeting is kept that short, people stand during the meeting. That’s why it is also called a stand-up meeting.

Based on the outcomes of this meeting the SCRUM Master will update either a Burn-down Chart or a Burn-up Chart.