Sprint Backlog

Das Sprint Backlog zeigt den Status des aktuellen Sprints in Form von Tasks. Das Task Board od. Story Board repräsentiert somit das Sprint Backlog.

Team Backlog

In his excellent presentation on Heartbeat retrospectives Boris Gloger makes a passing reference to a team backlog. This chimed with me since I’ve had teams ask recently “where do we put tasks we know we have to do but are not on the product backlog?”.

This is an interesting questions (IMHO). Should tasks exist if they are not on the PB? Who gets to prioritise? Is this a good way to handle technical debt?

I have used such a backlog but with certain rules. A team keen to keep track of previously accrued debt did maintain their own backlog. This could have items added to it by a team member at any time. The team would take items from the team backlog into the sprint often as an output from the retrospective. This worked because the product owner understood the importance of clearing away technical debt.

Impediments

  • Impediments sollten vom Scrum Master schnellstmöglich beiseitigt werden! (Remove impediments within 24 hours!)
  • Impediments durchaus öffentlich aushängen (zB „wir kriegen vom Management keine Rechner, die schnell genug sind…“)

User Story

Eine User Story ist keine Anforderung, nur der Platzhalter für nachfolgende Konversationen

Bsp: Als Benutzer möchte ich eine Rechnung ausdrucken können, um sie zu archivieren.

Template: As a <user role> I want <a feature> so that I can get <business value>.

Who want What Why?

The job of the team in an Sprint Planning question is to ask these 3 questions again and again. Each Backlog Item needs to be analyzed till you have the answers to this three questions:

 1. Who
 2. what
 3. Why

User Stories create pictures that answers these questions.

http://www.mountaingoatsoftware.com/presentations/119-introduction-to-user-stories

user-stories-for-agile-requirements-norwegian-developers-conference-2014.pdf

Akzeptanzkriterien

Akzeptanzkriterien sind ein wichtiger Hinweis für die Entwickler, wann eine Story fertig ist, nämlich wenn die Akzeptanzkriterien erfüllt sind.

z.B. User Story 'Als Coach möchte ich mein Profil auf der Webseite einstellen können, um … ' Mögliche Akzeptanzkriterien:

  • Stundensatz, Verfügbarkeit und Standort sind Pflichtfelder
  • Ein Coach kann seinen Lebenslauf als PDF bis max. 1MB Größe hochladen.
  • Rolle ist ein Pflichtfeld
  • Das Speichern des Profils darf nur maximal 1s dauern.

Release Plan

Total Story Points/Estimated Velocity = Anzahl der benötigten Sprints

#Sprints*#Members*#Days/Sprint*EUR=Aufwand

Zu Projektbeginn liegt die Velocity immer unter dem erwarteten Schnitt. (Infrastruktur, Projektstart)

Product Backlog

Das Product Backlog muss streng nach Business Value priorisiert sein. Prinzipiell sollten maximal 60 Items im Backlog liegen. Das Product Backlog lässt sich in 3 gleiche Teile splitten:

  • 1. Drittel - kleine Items, ca. 3 Sprints mit 5-10 Items pro Sprint (insg. max 30 Items)
  • 2. Drittel - mittlere Items, 3-6 Sprints mit je 5-10 Items, max. 30 Items
  • 3. Drittel - große Items, 6-12 Sprints, max. 30 Items

Das Product Backlog muss nicht alle Stories enthalten, aber natürlich zumindest jene für den nächsten Sprint gelten.

Selected Product Backlog

Das Selected Product Backlog enthält die für den kommenden Sprint vom Team commiteten Stories (keine Tasks).

Fixed Price, Fixed Date

Ein Fixpreis-Angebot zu legen, bevor ein Projekt begonnen hat ist im Wasserfall-Vorgehensmodell genauso sinnlos wie im Scrum-Prozess. Scrum bietet allerdings für den Kunden 2 völlig neuartige Optionen.

Change for Free

Eine Änderung in der klassischen Projektentwicklung wird meist als Katastrophe gesehen.

In Scrum kann der Kunde zu jedem Zeitpunkt Anforderungen, die noch nicht abgeschlossen/geliefert wurden ändern, also offene Stories beliebig tauschen.

Money for Nothing

Der Kunde kann zu jedem Zeitpunkt das Projekt mit aktuellem Projektstand abnehmen und somit die Kosten für zukünftige Features einsparen. Natürlich nur unter der Voraussetzung dass nach jedem Sprint ein fertiges Produkt geliefert wird. Dieses Produkt enthält jeweils die Features mit dem höchsten Business Value. Nachfolgende Features haben weniger Bedeutung, sind vielleicht irgendwann gar nicht mehr für das Endprodukt relevant.

Im 1. Drittel der Projektphase sind in der Regel 80% des Haupt-Business Values implementiert.

artefacts.txt · Zuletzt geändert: 2019/03/24 11:14 von admin
 
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki