Mit SQL CTE Werte aus vorheriger Zeile ermitteln

Dieses Beispiel soll die Problemstellung erkennen lassen. Es zeigt eine Tabelle mit fortschreitenden Verbrauch und Betriebsstundenzähler.

WerteTabelle

Betriebsstunden	Verbrauch
1	1,8
2	4,6
3	6,8
4	7,7
5	9,0
6	12,3
7	14,8
8	15,9

Unser Interesse gilt der Berechnung des Verbrauchs pro Stunde. Dazu muss man nur jeweils die Differenz aller Verbrauchswerte berechnen.

Betriebsstunden	Verbrauch	Minus	Verbrauch Zeile vorher	ist	Verbrauch pro Stunde
1	1,8	-	0,0	=	1,8
2	4,6	-	1,8	=	2,8
3	6,8	-	4,6	=	2,2
5	7,7	-	6,8	=	0,9
6	9,0	-	7,7	=	1,3
7	12,3	-	9,0	=	3,3
8	14,8	-	12,3	=	2,5
9	15,9	-	14,8	=	1,1

Wie mach man das mit SQL? Mein erster "Reflex" einer Lösung ging über ein CURSOR in einer Stored Procedure. Dies klappt natürlich auch. Besinnt man sich aber darauf, dass SQL eine Mengenabfragesprache ist, so kann man eine elegantere Lösung finden. Wir haben zwei Mengen. Unserer Ausgangstabelle und die Menge der Ausgangstabelle um eine Zeile verschoben. Wir JOINen beide Mengen und subtrahieren die Verbrauchswerte.

Wie aber nun einen JOIN auf die Zeile vorher machen?

Seit SQL 2005 gibt es die TSQL Funktion ROW_NUMBER(). Sie gibt als Integer die Nummer der Zeile zurück. Wir können den erforderlichen JOIN auf die Zeile vorher durchführen, indem wir in der zweiten Menge die ROW_Number minus 1 zurückgeben:

Menge von Spalte Verbrauch mit ROW_Number	Menge von Spalte Verbrauch mit ROW_Number minus 1
Verbrauch ROW_NUMBER 1,8 1 4,6 2 6,8 3 7,7 4 9,0 5 12,3 6 14,8 7 15,9 8	ROW_NUMBER - 1 Verbrauch 1-1 = 0 1,8 2 -1 = 1 4,6 3 -1 = 2 6,8 4 -1 = 3 7,7 5 -1 = 4 9,0 6 -1 = 5 12,3 7 -1 = 6 14,8 8 -1 = 7 15,9

Mit ROW_NUMBER und ROW_NUMBER minus 1 erhält man die zwei Mengen für der JOIN auf die vorherige Spalte:

Verbrauch	ROW_NUMBER	ROW_NUMBER - 1	Verbrauch
		0	1,8
1,8	1	1	4,6
4,6	2	2	6,8
6,8	3	3	7,7
7,7	4	4	9,0
9,0	5	5	12,3
12,3	6	6	14,8
14,8	7	7	15,9
15,9	8

Mit einer CTE können wir nun das Ergebnis gleich in einem Rutsch ausgeben:

   1:  WITH WerteTabelle(Betriebsstunden, Verbrauch) 

   2:  AS 

   3:  ( 

   4:    SELECT Betriebsstunden = 1, Verbrauch = 1.8  UNION 

   5:    SELECT Betriebsstunden = 2, Verbrauch = 4.6  UNION 

   6:    SELECT Betriebsstunden = 3, Verbrauch = 6.8  UNION 

   7:    SELECT Betriebsstunden = 4, Verbrauch = 7.7  UNION 

   8:    SELECT Betriebsstunden = 5, Verbrauch = 9.0  UNION 

   9:    SELECT Betriebsstunden = 6, Verbrauch = 12.3 UNION 

  10:    SELECT Betriebsstunden = 7, Verbrauch = 14.8 UNION 

  11:    SELECT Betriebsstunden = 8, Verbrauch = 15.9 

  12:  ) 

  13:  ,Menge1(Nr, Betriebsstunden, Verbrauch) 

  14:  AS 

  15:  ( 

  16:    SELECT 

  17:      ROW_NUMBER() OVER (ORDER BY Betriebsstunden) AS 'Nr', 

  18:      Betriebsstunden, 

  19:      Verbrauch 

  20:    FROM WerteTabelle 

  21:  ) 

  22:  ,Menge2(NrMinusEins, Betriebsstunden, Verbrauch) 

  23:  AS 

  24:  ( 

  25:    SELECT 

  26:      (ROW_NUMBER() OVER (ORDER BY Betriebsstunden) - 1) AS 'NrMinusEins',  

  27:      Betriebsstunden, 

  28:      Verbrauch 

  29:    FROM WerteTabelle 

  30:  ) 

  31:   

  32:  SELECT 

  33:    Menge1.Betriebsstunden, 

  34:    Menge1.Verbrauch, 

  35:    Menge2.Verbrauch AS 'Verbrauch Zeile Vorher', 

  36:    Menge2.Verbrauch - Menge1.Verbrauch AS 'Verbrauch pro Stunde' 

  37:  FROM 

  38:    Menge1 

  39:  INNER JOIN Menge2 ON Menge1.Nr = Menge2.NrMinusEins

  40:   

Ergebnis:

Certified Scrum Master (CSM)

Am 12. - 13.04.2010 nahm ich an einem Training zum Certified Scrum Master (CSM) teil. Referent war Boris Gloger. Das Training dauerte 2 Tage - inklusive eines abendlichen Scrum-Cookings. Das Zertifikat erhält man im Anschluss, indem den Online-Test "Certified ScrumMaster Candidate Evaluation" auf www.scrumalliance.org durchführt.

Embedded Linux Router (Homemade)

1. Zutaten

Fujitsu Futro S 400	Linux Router fli4l
bootet von CF Karte On Board LAN Leise (weil ohne Lüfter) Stromsparend PCI Slot für DSL Modem  LPT Port für LCD Display Günstig (Werksverkauf 40 €)	Mini Linux Router Open Source Viele Zusatzpakete verfügbar Weit verbreitet & stabil Hardware wird unterstützt Günstig (0 €)
AVM PCI DSL Modem	LCD Display
Treiberunterstützung für Linux Weit verbreitet Günstig (eBay 10 €)	Zur Basis-Statusanzeige Man braucht keinen PC Monitor Über LPT Kabel anschließbar Kein Treiber / Controller nötig Günstig (eBay 12 €)

2. Zubereitung

Was war bei der Konfiguration zu beachten?

Auf der Projektseite von fli4l finden sich eine Fülle von Anleitungen, Anregungen und Ideen sich seinen Router zusammenzustellen. Selbst mit einem Windows PC, kann das Image für CF Karte erstellt werden:

Konfiguriert man den HTTP Server für das Monitoring, kann man vom PC im Heimnetzwerk aus den Status des Routers überwachen und einfache Steuerungsaufgaben durchführen.

 

3. Garzeit

Jetzt wird noch geschmort: Das LCD Panel wird an ein altes LPT-Druckerkabel angelötet. Am besten schaltet man noch ein Potentiometer davor um die Helligkeit regeln zu können. Das LPT Druckerkabel wird dann an die parallele Schnittstelle abgeklemmt. Vorher muss noch das LDC Modul konfiguriert werden. Und fertig ist das Mini-Display mit Statusanzeige…

4. Kredenzen

Nach ein paar Test war der Router fertig und er konnte seinen Dienst aufnehmen. 

Mein DSL Anschluss hat des Öfteren Störungen. Es wird die Verbindung zum Netz-Provider kurzzeitig getrennt. Dies brachte meinen alten Router regelmäßig zum Abstürzen. Meist half nur ein harter Reset. Mein neuer Router dagegen läuft sehr stabil. Bei einer Netztrennung verbindet er sich sofort wieder und man hört ein akustisches Signal das er dies tut (Siehe Konfiguration IMOND_BEEP='yes'). Und so läuft und läuft und läuft der Router:

5. Abschmecken

Die Konfiguration des Routers wird pro Modul über  Konfig-Dateien (z. B. base.txt., dsl.txt, etc.) durchgeführt.  Die Konfigurationsparameter müssen insbesondere an die Hardware angepasst werden (CF Karte,  DSL Modem und LCD Display). Werden Module nicht benötigt, kann man die entsprechenden Konfig-Dateien löschen.

Aufgeführt sind hier die wichtigsten Settings aus den verwendeten Konfig-Dateien.

a) Konfiguration base.txt

#-----------------
# General settings
#-----------------
HOSTNAME='futro'             # name of fli4l router
PASSWORD='geheim'            # password for root login 
BOOT_TYPE='hd'               # boot device (fd, hd, cd, etc)
MOUNT_BOOT='rw'              # mount boot device (ro, rw, no)
BOOTMENU_TIME='1'            # waiting time of bootmenu 
#---------------
# Debug Settings
#---------------
DEBUG_STARTUP='no'           # write an execution trace of the boot
                             # Wert auf 'yes' setzen,
                             # um Fehler beim Booten zu finden
#----------------------
# Ethernet card drivers
#----------------------
NET_DRV_N='1'                # number of ethernet drivers to load
NET_DRV_1='r8169'            # 'r8169' für Futro onboard LAN 
NET_DRV_1_OPTION=''          # additional option (nicht notwendig)
#-------------------------------------
# Ether networks used with IP protocol
#-------------------------------------
IP_NET_N='1'                 # number of IP ethernet networks, usually 1
IP_NET_1='10.0.0.1/8'        # IP address of your ethernet card 
IP_NET_1_DEV='eth0'          # required: device name like ethX
#---------------------------
# Packetfilter configuration
#---------------------------
PF_NEW_CONFIG='yes' # new style packet filter config
Config des Paketfilters dem eigenen Netzwerk anpassen!
(Zum Starten Beispiel aus Doku nehmen)
#-------------------------------------------
# Simple DMZ setup for dial-up based routers
#-------------------------------------------
OPT_DMZ='no'                 # Dafür würde man ein weiteres  
                             # LAN Interface benötigen! 
                             # (Futro S400 hat leider nur eines) 
#--------------------------------------------------
# Domain configuration (DNS, DHCP-Server and HOSTS)
# (Details 'ausgelagert' im Package DNS_DHCP.txt)
#--------------------------------------------------
DOMAIN_NAME='home.test'      # your domain name
DNS_FORWARDERS='194.8.57.12' # DNS servers of your provider
                             # (Ich nutze: ns.n-ix.net)
#--------------------
# imond configuration
#--------------------
START_IMOND='yes'            # start imond: yes or no
 IMOND_USE_ORIG='yes'        # use the original version of imond
 IMOND_PORT='5000'           # port (Don't open it to the outside!)
 IMOND_PASS='geheim'         # imond-password, may be empty
 IMOND_ADMIN_PASS='geheim'   # imond-admin-password, may be empty
 IMOND_LED=''                # tty for led: com1 - com4 or empty
 IMOND_BEEP='yes'            # beep if connection going up/down
 IMOND_LOG='yes'             # log /var/log/imond.log: yes or no
 IMOND_LOGDIR='/var/log'     # log-directory, e.g. /var/log
 IMOND_ENABLE='yes'          # accept 'enable/disable' commands
 IMOND_DIAL='yes'            # accept 'dial/hangup' commands
 IMOND_ROUTE='yes'           # accept 'route' command
 IMOND_REBOOT='yes'          # accept 'reboot' command

#------------------------------
# Generic circuit configuration
#------------------------------
IP_DYN_ADDR='yes'            # use dyn. IP addresses (most providers do)
DIALMODE='auto'              # standard dialmode: auto, manual, or off

g) Konfiguration tools.txt

#------------------------
# Optional package: Tools
#------------------------

# Alle Tool aktivieren, die man auf dem Linux Router benötigt
# Beispielsweise Z. B.  traceroute   
       
OPT_TRACEROUTE='yes'             # install traceroute    
OPT_TRACEROUTE6='yes'            # install traceroute6   

e) Konfiguration httpd.txt

#----------------------------------------------
# Optional package: HTTP server for monitoring
#----------------------------------------------
OPT_HTTPD='yes'                 # install monitoring webserver
HTTPD_PORT='81'                 # TCP port for webserver
HTTPD_USER_N='1'                # number of users for the webserver
HTTPD_USER_1_USERNAME='bernie'  # name of the 1st user
HTTPD_USER_1_PASSWORD='geheim'  # password of the 1st user
HTTPD_USER_1_RIGHTS='all'       # access rights of the 1st user
HTTPD_GUI_LANG='auto'           # choose language for web administration
HTTPD_GUI_SKIN='default'        # choose any supported skin
HTTPD_ARPING='yes'              # activate arping to hosts
                                # view arp state of hosts

d) Konfiguration hd.txt

#---------------------------------------
# Optional package: HD controler drivers
#---------------------------------------
OPT_HDDRV='yes'      # install drivers for harddisk
HDDRV_N='1'          # number of HD drivers to load, usually 1
HDDRV_1='ide-hd'     # 1st driver: name (e.g. ide-hd)
                     # (CF Karte als IDE HD einbinden)
HDDRV_1_OPTION=''    # 1st driver: additional option

#---------------------------------------------
# Optional package: install on HD or Flashdisk
#---------------------------------------------
OPT_HDINSTALL='no'   # install on harddisk 
                     # (Nur notwendig, wenn über LAN installiert wird)
#-----------------------------------------------
# Optional package: Power-Down for IDE Harddisk
#----------------------------------------------
OPT_HDSLEEP='no'     # power down HD after some time
HDSLEEP_TIMEOUT='5'  # wait 2 minutes until power down
                     # (Für CF Karten nicht notwendig)

Sprint Review & Retrospektive mit Scrum for Team System

In diesem Teil beschreibe ich, wie wir Scrum for Team System bei Sprint Reviews und bei Sprint Retrospektiven nutzen. Und weshalb wir Impediments nicht mit Scrum for Team System verwalten…

Teil 1: Sprint Planung
Teil 2: Daily Scrums
Teil 3: Sprint Review & Retrospektive

Teil 3: Sprint Reviews & Retrospektive

3.1 Sprint Review
Zu dem Sprint Review treffen sich die Team-Mitglieder, die Product Owner oder Fachexperten. Es wird an einem Beamer das Product Increment vorgestellt.
War die Implementierung erfolgreich, werden die entsprechendes Product Backlog Items auf "done" gesetzt. Entspricht ein Product Backlog Item aber nicht den Vorstellungen, muss nachgebessert werden. Solch ein Product Backlog Item verweilt mit dem Status "in Progress" im Product Backlog und steht mit der höchsten Priorität für den Folgesprint an oberster Stelle. Wir nutzen üblicherweise das Task Board, um den Status von PBIs zu setzen.

3.2 Retrospektive
Zur Retrospektive treffen wir uns nach einem Sprint für eine Stunde, um die Aktivitäten des Sprints zu reflektierene:

• Was war gut?
• Was war nicht so gut?
• Was wollen wir besser machen? 

Jeder im Team liefert "Input".Die Ergebnisse halten in einem Work Item Type "Retrospective" fest:


Da war doch noch was? Richtig die Impediments…

3.3 Impediments (Hindernisse) besser auf einem Whiteboard!
Impediments hindern das Team daran das Produkt-Inkrement fertig zu stellen. Hindernisse müssen schnell aus dem Weg geräumt werden. Dies zu tun ist Aufgabe des SCRUM Masters. Ein Hindernis kann beispielsweise "Mehr RAM für den Build-Server" sein, oder "es fehlt noch die Prozessabsprache mit Fachabteilung XY". Unsere Hindernisse sind vielschichtig und meist nur kurzlebig. Darum verwalten wir sie nicht über das WorkItemType "Impediments" in TFS, sondern auf einem Whiteboard - für jeden im Team sichtbar!

Daily Scrums mit Scrum for TeamSystem

In diesem Teil beschreibe ich, wie wir Scrum for Team System in unseren Daily Scrum Meetings einsetzen.

Teil 1: Sprint Planung
Teil 2: Daily Scrums
Teil 3: Sprint Review & Retrospektive

Teil 2: Daily Scrum Meetings

Unsere Daily Scrums finden immer vor dem gemeinsamen Mittagessen statt und dauern ca. 15 Minuten. Reihum beantwortet jeder die Punkte:

• Was hast Du seit dem letzten Daily Scrum gemacht?
• Was wirst Du bis zum nächsten Daily Scrum machen?
• Wo hast Du Hindernisse?

Wir nutzen das digitale Task Board, um die angesprochenen Punkte festzuhalten. Bei der Frage "Was hast Du seit dem letzten Daily Scrum gemacht?" verweisen wir an einem großen Monitor auf die entsprechenden gelben Zettel. Wir stellen kurz den Verlauf, Fortschritt, Kontext, etc. der eigenen Punkte dar und schätzen - falls möglich - die noch verbleibende Zeit. Auch hier ist es so, dass wir die noch offenen Stunden nur über den Daumen schätzen. Es kommt nur auf den geimeinsammen Fortschritt an.

Das verschieben der gelben Zettel (die Sprint Backlog Items) erfolgt komfortabel über drag&drop:

Aus dem "Schieben" der Sprint Backlog Items (SPI) während der Daily Scrums ergeben sich automatisch tolle und aussagekräftige Burndown Charts mit Trend-Forecast:

Die digitale Version des Task Boards bringt zwar einerseits viel positives, andererseits fehlt hier das haptisches Erleben von genau "meiner gelben Karteikarte", die ich am Whiteboard auf "done" setze. Ich habe schon gehört, das Teams zwei Task Boards nutzen. Ein klassisches Whiteboard mit konventionellen Karteikarten und daneben eine digitale Version. Beide werden nach jedem Daily Scrum synchronisiert. Auch eine gute Idee!

Sprint Planung mit Scrum for Team System

Nach nun 20 Sprints hat sich für unser Team ein optimaler Ablauf der Organisation von Sprints eingestellt. Als Werkzeuge nutzen wir Excel, TFS, Scrum for Team System (Conchango) und das Task Board for Team System. Ich möchte Euch drei Blog-Teilen vorstellen, wie wir die Tools für SCRUM nutzen und wie sich der Ablauf der Sprints damit gestaltet.

Teil 1: Sprint Planung
Teil 2: Daily Scrums
Teil 3: Sprint Review & Retrospektive

Teil 1: Sprint Planung

Wir bauen seit unserem 4. Sprint alle Artefakte der Sprints in TFS auf. Die Benutzung von TFS war zu Begin zeitaufwendiger als der Einsatz von Karteikarten auf altbewährten Whiteboards. Man hat aber schnell eine gewisse Routine und wird umgehend belohnt durch automatisch erzeugte Burndown-Charts, User Stories, Backlogs, Testpläne oder Versionsplänen. All diese Informationen bereitet TFS zeitnah und komfortabel auf. Und dafür lohnt sich Mühe und Zeitaufwand wirklich!
Die Sprint Planung steht am Anfang jedes Sprints. Folgender Ablauf (und Zeitaufwand) hat sich etabliert:

1. Kapazitätsplanung des Teams für den Sprint-Zeitraum
   ( 15 Minuten)
   
2. Aufbau eines TFS Work Items vom Typ "Sprint"
   ( 1 Minute)
   
3. Festlegen aller Sprint Backlog Items (SPI) für die anstehenden Product Backlog Items (PBI)
   ( 1 Nachmittag)
   
4. Commitments des Teams zum Sprint-Ziel
   (10 Minuten)
   
5. Übertragen der Ergebnisse ins TFS
   (30 Minuten)
   

a) Kapazitätsplanung des Teams für den Sprint-Zeitraum
Bevor man die Sprintplanung beginnt, muss die Kapazität des Teams im Sprint-Zeitraum erfragt werden. Ich habe hierfür eine Excel Vorlage erstellt. In dieses trägt jedes Teammitglied ein, wie viele Tage es pro Woche im anstehenden Sprint-Zeitraum zur Verfügung steht.

	Fritz	Günther	Anna	Gerd
1.Woche	3	5	5	5
2.Woche	5	0	5	5
3.Woche	5	0	5	4
Summe (Tage)	13	5	15	14
Summe (Std)	104	80	120	112
Korrekturfaktor	0.9	0.9	0.8	0.7
Stunden (ca.)	93	72	96	78	330

Für Teammitglieder, die ungeliebte Nebenjobs haben, welche nur schwer Teil der Planung sein können, haben wir empirisch einen Korrekturfaktor eingebracht. Dadurch verbessen wir unsere Zeitschätzung. Anna ist unsere Build-Masterin (auch für andere Teams) und kann nur zu 80% entwickeln, Gerd unterstützt den Support und hat daher einen Faktor von 0.7 (70%). Hier geht es nicht darum die genaue Stundenzahl mit "Kommastelle" auszurechnen. Wichtig ist lediglich die Größenordnung.

b) Aufbau eines TFS Work Items vom Typ "Sprint"
Nun wird ein neues TFS Work Item vom Typ "Sprint" angelegt.
Dies erfolgt über den Menüeintrag Add Work Item.



Die aus der Kapazitätsplanung ermittelten Stunden werden im Feld Capacity (hours) eingetragen.
Im Feld Sprint Name wird die Iteration ausgewählt (Iterationen werden in den TFS Project Settings angelegt).
Das Feld Sprint Goal bleit noch leer und wird erst nach Ende des Planungsmeetings mit der Zusammenfassung des Commitments zum Sprint-Ziel gefüllt.

c) Festlegen aller Sprint Backlog Items (SPI) für die anstehenden Product Backlog Items (PBI)
Jetzt endlich kommen wir zum Kernstück: zur eigentlichen Sprint-Planung!
Hierfür trifft sich das Team in einem Raum. Die anstehenden PBI sind bekannt nun gilt es für jedes der PBIs die SPIs zu ermitteln. Dazu steuert jedes Teammitglied seinen Input für die anstehenden Aufgaben bei. Wir halten dies einer Excel Tabelle fest, die wir mit einem Beamer an die Wand projizieren. Das ist oft sehr dynamisch. Es kommen Punkte hinzu, es werden welche gestrichen, es wird geschätzt, verteilt, zusammengefasst… Diese Dynamik ist der Grund weshalb wir alle Punkte zunächst in Excel festhalten und nicht gleich in TFS anlegen. WorkItems können nicht gelöscht, zusammengeführt oder auf gesplittet werden.

Wie sieht das Excel Template aus?

Unter die Liste der anstehenden PBIs schreiben wir alle notwendigen SPIs und schätzen deren Aufwand.

Legende
Product Backlog Item (nach Prio sortiert)	Summe Stunden
Sprint Backlog Items (in dieser Planungsrunde festgelegt)	Stunden geschätzt

Über die Summenfunktion von Excel werden die Stunden für die PBIs ermittelt. Mit der Kapazität im Hinterkopf ist schnell klar welche PBIs im Sprint umsetzbar sind und welche nicht mehr.
Das untere Beispiel zeigt eine Planungstabelle in Excel. Die User Story D kann beispielsweiser nicht mehr durchgeführt werden, da die Kapazität bereits mit User Story C ausgeschöpft ist.

1 User Story A	120
Neues Datenfeld "expired" in DB	4
Property und Validierung in MT	8
Unit Test	4
GUI erweiterung	4
usw…
2 User Story B	88
SPI 1	8
SPI 2	2
usw…
3 User Story C	120
SPI 1	6
SPI 2	6
usw…
4 User Story D	48
SPI 1	6
SPI 2	6
usw…

Hier ein Screenshot der Sprint-Planung mit Excel:


d) Commitment des Teams zum Sprint-Ziel
Zum dem Abschluss der Sprint-Planungsrunde muss das Team ein Commitment zum Sprint-Ziel abgeben.
Das Sprint-Ziel ist eine knappe Zusammenfassung dessen, was in dem geplanten Sprint geleistet wird.

e) Übertragen der Ergebnisse ins TFS
Für die Team-Mitglieder ist die Planung nun abgeschlossen. Daraufhin bereite ich in TFS alles für den kommenden Sprint vor. Dazu müssen alle Product Backlog Items (PBI) aktualisiert und die neuen Sprint Backlog Items (SPI) angelegt werden.
Zunächst weise ich allen angegangenen PBI den kommenden Sprint zu.

Über die Work Item Liste sortiere ich Product Backlog Items nach Business Priority.
Hier kann ich der Reihe nach schnell allen betroffenen PBIs im Feld Release and/or Sprint den Sprint zuweisen.

Sind alle PBIs aktualisiert mache ich mich an die dazugehörenden SPI. Dies kann man ebenfalls über den Team Explorer erledigen. Ich nutze dafür aber das Task Board for Team System. Diese Tool macht diese Arbeit wesentlich effizienter und nach 2-3 Sprints hat man die Lizenzkosten von ca. 50€ locker amortisiert.

Man startet das Task Board, wählt den gewünschten Sprint aus und es erscheint eine ansprechende WPF Oberfläche, die an ein Task Board auf einem Whiteboard erinnert.



Alle SPIs zu einem PBI kann man nun rasch anlegen,
indem man über das Kontextmenü den Menüeintrag Add Sprint Backlog Item aufruft.

Unter Title und Description trägt man ich die wichtigsten Punkte zum SPI ein.
Das Feld Description bleibt tatsächlich oft leer.
Wichtig ist es die Stunden zum SPI unter Estimanted Effort und unter Work Remainig einzutragen.
Das Feld Assigned To bleibt zu Beginn leer. Erst während der Daily Scrums teilen sich Team Mitglieder Aufgaben selbst zu.

Sind alle PBIs aktualisiert und alle SPIs aufgebaut kann der Sprint beginnen…

Team Velocity

Team Velocity = Story Points pro Sprint.
Wir hatten einige Sprints hinter uns, nun war der Velocity-Report interessant. Hier sieht man wie viele Story Points das Team in den Sprints geschafft hat. Nun ergab sich zwar ein wirklichkeitsnaher Mittelwert von 34 Story Points. Aber es fanden sich auch Werte von 5 bis 82. Woher kommen diese Schwankungen im Velocity Report?
1. PBIs laufen über mehrere Sprints.
Ja wir haben sie! Diese Product Backlog Items (PBIs), die von einem Sprint zum nächsten "schlüpfen" und nie so richtig fertig werden. Das klassische "Everything in Progress" Problem. Es fehlt halt nur noch ein Review mit der Fachabteilung oder ein Test einer Daten-Schnittstelle. Aber die Ressourcen außerhalb des Teams sind nicht verfügbar, krank, im Urlaub oder mit anderen "Prio 1 Themen" beschäftigt. Wir können dann das Product Backlog Items (PBIs) nicht vollständig abschließen. Es wandert in den nächsten Sprint. Wird das PBI schließlich auf "Done" gesetzt, wertet TFS die Story Point vollständig zum aktuellen Sprint, obwohl der Großteil der Arbeit in einem vorigen Sprint verrichtet wurde.
Fazit: Blockieren Ressourcen außerhalb des Team den Fortschritt muss man leider damit leben
2. Reporting Problem: Story Points tauchen im Folgesprint auf.
Ein ähnliches Problem liegt hier vor. Auch hier entscheidet der Tag an dem das PBI auf "Done" gesetzt wurde, für welchen Sprint dessen Story Points zählen. Oft wurden die Story Points erst im Folgesprint angezeigt (rote Pfeile). Wir hatten das PBI aber rechtzeitig fertiggestellt! Was war passiert?


Den letzen Daily Scrum eines Sprints hielten wir immer am Vormittag des Planungstages für den Folgesprint ab. Hier haben wir oft noch offenen Punkte auf "done" gesetzt (meist irgendwelche Branching- ,Build- oder Infrastruktur-Aufgaben). Und das war das Problem. Die PBIs zählten dann schon zum nächsten Sprint, dessen Zeitintervall schon begonnen hatte. Wir haben das Problem dadurch gelöst, dass die Planung eines Folgesprints noch im Zeitintervall des aktuellen Sprints stattfindet. Dann kann man auch noch am letzen Tag Punkte auf "done" setzen, ohne dass das Reporting beleidigt ist…
Fazit: Story Points werden zu genau dem Sprint-Zeitintervall gezählt in dem der Status des PBI auf "Done" gesetzt wurde.