5 Most Powerful Acronyms for Agile Coaches

AcronymsPhoto by tuchodi is licensed under CC BY-SA 2.0

Personally I love acronyms, because they serve me as mnemonic for some of the important stuff that I shouldn’t forget as an agile coach. Further they are simple to teach and made to stick. Here are my top 5 acronyms for agile coaches:

FROCC

The Scrum values can be easily remembered with the acronym “FROCC”, the misspelled frog:

Focus – we focus on a few things at a time
Respect – we respect our colleagues like we want to be respected
Openness – we express our thoughts about how we are doing
Courage – the team gives us the courage to take greater challenges
Commitment – we are committed to success

Source: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

DEEP

A well refined product backlog is “DEEP”:

Detailed appropriately – the details are added over time
Estimated – backlog items are estimated
Emergent – a product backlog changes over time
Prioritized – the most valuable items are on top

Source: https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep

MoSCoW

When it comes to prioritizing your backlog “MoSCoW” can serve you well. Distinguish your features by:

Must have – the requirement is core and must be satisfied for success
o
Should have – the requirement is should be satisfied for success
Could have – the requirement is desirable but not necessary for success
o
Won’t have – the requirement will not be implemented

Source: http://en.wikipedia.org/wiki/MoSCoW_method

INVEST

“INVEST” in well-defined user stories. A user story must be:

Independent – the user story has no dependency to other stories
Negotiable – user stories can always be changed and rewritten
Valuable – a user story must deliver value to the end user
Estimable – you must be able to estimate the size of a user story
Small – a user story must fit into a sprint, but should be smaller
Testable – a user story must be testable

Source: User Stories Applied (Mike Cohn)

SMART

Make (iteration) goals always “SMART”:

Specific – target a specific goal
Measurable – quantify or at least suggest and indicator of progress
Achievable – be realistic
Relevant – check relevancy of the goal
Time-bound – assign a target-date

Source: http://en.wikipedia.org/wiki/SMART_criteria

Any other suggestions?

Advertisements

INVEST In Good User Stories

Wir verwenden User Stories tag-täglich und so ist es wichtig sich hin und wieder in Erinnerung zu rufen, was denn ein gute User Story ausmacht.

Ron Jeffries beschreibt folgende drei Bestandteile einer User Story:

  • written description or short title of the story used as a token for planning and as a reminder to have conversations (Cards)
  • Conversations about the story that serve to flesh out the details of the story (Conversations)
  • Acceptance tests that convey and document details and that can be used to determine when a story is complete (Confirmations)

Weiters beschreibt Cohn (2004) folgende Kriterien einer guten User Story:

  • Independent
  • Negotiable
  • Valueable to users / customers
  • Estimatable
  • Small
  • Testable

Independent:

Unabhängige User Stories sind technisch und funktional klar voneinander abgegrenzt und beeinflussen sich nicht. Eine Abhängigkeit würde zum Beispiel entstehen, wenn in Story A und Story B (teilweise) die selbe Funktionalität implementiert wird oder Story A auf Funktionalität von Story B angewiesen ist und/oder vice versa. Abhängigkeiten in User Stories erzeugen auch Abhängigkeiten zwischen den Entwicklern und Teams, die diese User Stories letztlich implementieren. Erhöhter Kommunikations- und Koordinationsaufwand ist die Folge. Ein weiteres Problem ergibt sich beim Schätzen: In welcher Story soll die überschneidende Funktionalität von A und B geschätzt werden? Die häufigste Antwort lautet: Jene Story die als erstes Implementiert wird (nehmen wir an das sei Story A), soll den gemeinsamen Anteil in der Schätzung beinhalten. Dann braucht die Schätzung von Story B diesen Anteil nicht zu beinhalten, da diese Funktionalität ja nur einmal implementiert werden muss (was bereits in Story A passiert). Jedoch bedeutet das, dass bereits zum Zeitpunkt des Schätzens die Reihenfolge der Abarbeitung von User Story A und B implizit festgelegt wird, was keinesfalls wünschenswert ist, da eine unbestimmte Zeit zwischen Schätzung und Umsetzung liegen kann! Was passiert wenn zwischen Schätzung und Umsetzung der Kunde entscheidet, dass Story A nicht mehr im Scope ist? – Story B ist dann zu gering geschätzt, da der gemeinsame Anteil von A und B, nur in Story A geschätzt wurde.

Negotiable:

User Stories sind niemals als starres Dokument zwischen Kunde, Product Owner, Team oder sonst jemandem zu sehen, sondern der Inhalt ist zu JEDER Zeit verhandelbar und veränderbar! Auch Artefakte wie eine Definition of Ready ändern daran nichts! User Stories sind keine Verträge über Requirements, die in einer Software umgesetzt werden müssen. User Stories entstehen beim/mit Kunden und werden gemeinsam mit dem Product Owner, dem Entwickler-Team und dem Kunden iterativ ausdefiniert. Kommunikation ist hier angesagt und keine peniblen Definitionen von Klauseln und Requirements! Das agile Manifest spricht dazu eine sehr deutliche Sprache:

Customer collaboration over contract negotiation

Valueable to users:

Die Formulierung einer User Story wird immer aus der Sicht des Users (einer User-Rolle) getroffen. Das ist deshalb so wichtig, da letztendlich der Benutzer derjenige ist, der einen Mehrwert durch die korrekte Implementierung der User Story erfahren soll. User Stories, die nur technische Details beschreiben, sind daher keine korrekten User Stories, da diese für den Benutzer keinen ersichtlichen Mehrwert liefern.

Estimatable:

Wie schon vorhin angesprochen müssen User Stories vom Entwickler-Team unabhängig voneinander schätzbar sein. Gründe warum eine User Story nicht schätzbar ist, können sein:

  • Entwickler haben zu geringes Domänenwissen
  • Entwickler haben zu geringes teschnischen Wissen
  • Die User Story ist zu groß

Punkt 1 und 2 lässt sich durch eine gute Teamzusammenstellung (Cross-Funktional und gute Balance aus Senior u. Junior Entwicklern) und durch gewissenhafte Vorbereitung der User Stories minimieren. Punkt 3 lässt sich durch Teilung der User Story in kleinere Sub-Stories lösen. 

Small:

Große User Stories sind schwer schätzbar, dadurch schlecht planbar und erhöhen das Risiko durch Verzögerungen enorm (vgl. Reinerstsen 2014). Daher gibt es eine wichtige Regel: Werden User Stories vom Team als zu groß angesehen müssen diese ausnahmslos geteilt werden und so in kleinere Sub-Stories zerlegt werden. Es gibt eine ganze Reihe an Hilfmitteln für das Story Slicing:

Testable:

Die Formulierungen der User Stories (genauer: der Akzeptanzkriterien) müssen so gewählt werden, dass diese möglichst automatisiert getestet werden können. Ist ein automatisiertes Testen nicht möglich ist dies manuell durchzuführen. Eine gute Praxis ist, sich für jedes Akzeptanzkriterium zu überlegen, ob und wie dieses getestet werden kann. Ist die Testbarkeit nicht gegeben muss das Kriterium abgeändert werden um Testbarkeit zu erzielen.

Quellen:

COHN, M.: 2004. User Stories Applied For Agile Software Development, Addison Wesley, S. 17-29

REINERSTEN, D.: 2014. The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing