Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)
Advertisements

Anforderungen schätzen – aber WIE?

Es gibt wohl kaum ein kontroverseres Thema in der agilen Softwareentwicklung als des Schätzen der Anforderungen. Diesen Eindruck habe ich jedenfalls, wenn ich täglich mit Product Ownern, Entwicklerteams und Scrum Mastern über die Methodik und die verwendeten Einheiten beim Schätzen diskutiere. Welche Einheit ist die beste? Sollen abstrakte Größen, wie Story Points, oder lieber absolute Größen, wie Stunden oder Personentage, für die Schätzung von Anforderungen verwendet werden? Ich habe das Gefühl, dass sich hier keine einheitliche Herangehensweise etabliert hat. Ein Blick in die Literatur zeigt auch hier keine einheitliche Meinung über die Einheit der Schätzungen:

Kent Beck sagt zum Schätzen in der 2. Auflage seines Buches “Extreme Programming Explained” folgendes:

“The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three points. […] I prefer to work with real time estimated now, making all communication as clear, direct and transparent as possible.”

Boris Gloger vertritt in seinem Buch über Scrum die Meinung, dass nur eine Schätzung in abstrakten Größen (keinesfalls Zeiteinheiten) zum Schätzerfolg führt.

Mike Cohn legt sich in seinem Buch “Succeeding with Agile: Software Development Using Scrum” nicht genau fest und lässt die Entscheidung ob “Story Points” oder “Ideal Work Hours” verwendet werden bei den Teams.

Ken Schwaber und Mike Beedle unterstützen die Ansicht von zeitunabhängigen Schätzungen in ihrem Buch “Agile Development with Scrum“:

“Duration is not considered in Scrum. Work remaining and date are the only variables of interrest.”

Es sieht also fast so aus als ob hier jeder seinen eigenen Weg finden muss. Aber wo liegen die Vor- und Nachteile von konkreten bzw abstrakten Einheiten in der Praxis?

Vorteile Nachteile
Konkrete Einheiten (Personentage, Ideal Work Hours, Stunden,…)
  • Hohe Transparenz
  • Einfache Kommunikation des Aufwands
  • Kompatibilität zu traditionellen Methoden
  • Wenig Konflikte da bekannte Methode
  • Selbstbetrug durch festhalten an unrealistischen Schätzungen
  • Ungenaue Schätzungen selbst bei sehr erfahrenen Entwicklern
  • Steigerung der Velocity nicht feststellbar

 

Abstrakte Einheiten (Story Points, Kühe, Bäume,…)
  • Fokus auf Funktionalität, die dem Kunden einen Nutzen liefert
  • Genauere Schätzungen auch von unerfahrenen Entwicklern
  • Steigerung der Velocity feststellbar
  • Inkompatibilität mit Arbeitsweise anderer Abteilungen
  • Klärung was Einfluss auf die Größe der Schätzung hat ist oft schwierig (Funktionalität, Komplexität, Rahmenbedingungen,…)
  • Erhöhtes Konfliktpotential

Unabhängig welche Methode zur Anwendung kommt, sind Referenzen (z.B. Referenz User Stories) eine große Hilfe um vergleichbare Schätzungen über die Zeit und über Teams hinweg erzielen zu können. Neben der Einheit spielt auch die Schätz Methode eine wesentliche Rolle – also wie der eigentlich Prozess des Schätzens abläuft. Dazu aber in einem anderen Blogpost mehr.