Das Geheimnis von Story Points und agilen Schätzungen

Mit einer guten Schätzung können Product Owner die Effizienz und Wirksamkeit optimieren. Darum ist sie überaus wichtig. 

Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 

There's no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let's look at some ways to make agile estimates as accurate as possible.  

Collaborating with the product manager

In agile development, the product manger is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product manager new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that's good: those questions help the entire team understand the work more fully. For product managers specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it's not uncommon for a product owner to reorder items on the backlog. 

Agile Schätzung ist Teamarbeit

Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, design changes require not only the design team's input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.

Achte also darauf, dass dein Team nicht unter in einem Vakuum erstellten Schätzungen zu leiden hat. Denn das ist ein sicherer Weg zum Misserfolg! 

Story Points oder Stunden

Herkömmliche Softwareteams erstellen Schätzungen in einem zeitbasierten Format, also in Tagen, Wochen und Monaten. Viele agile Teams sind jedoch zu Story Points übergegangen. Mithilfe von Story Points wird der relative Aufwand einer Aufgabe in einem fibonacciartigen Format bewertet: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Auch wenn es widersprüchlich klingen mag, ist diese Abstraktion tatsächlich hilfreich, da das Team damit die Schwierigkeit einer Aufgabe strenger beurteilt. Hier sind einige Gründe, die für die Verwendung von Story Points sprechen:

  • Nicht projektrelevante Aufgaben für ein Teammitglied, die sich unweigerlich in unseren Tagesablauf einschleichen, wie E-Mails, Meetings und Interviews, werden bei Datumsangaben nicht berücksichtigt.
  • Datumsangaben schaffen eine emotionale Verbindung, während eine relative Schätzung eine emotionale Verbindung vermeidet.
  • Jedes Team schätzt Aufgaben nach einem unterschiedlichen Maßstab ab, was bedeutet, dass die (in Punkten gemessene) Velocity ganz selbstverständlich unterschiedlich ist. Das ermöglicht allerdings, die Velocity als politisches Druckmittel einzusetzen.
  • Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
  • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

Story points and planning poker

Teams, die mit Story Points beginnen, spielen oft das sogenannte Planning Poker. Bei Atlassian wird Planning Poker regelmäßig im gesamten Unternehmen gespielt. Das Team nimmt eine Aufgabe aus dem Backlog und bespricht diese kurz. Dann überlegt sich jedes Teammitglied im Kopf eine Schätzung. Anschließend halten alle eine Karte mit der Zahl hoch, die der jeweiligen Schätzung entspricht. Wenn sich alle einig sind, großartig! Wenn nicht, muss sich das Team etwas Zeit nehmen (aber nicht zu viel, nur einige Minuten), um der Ursache für die abweichenden Schätzungen auf den Grund zu gehen. Bedenke dabei aber, dass die Schätzung eine eher allgemein gehaltene Aktivität ist. Sollte sich das Team zu sehr in Einzelheiten verzetteln, einmal tief durchatmen und die Diskussion wieder auf ein allgemeineres Niveau bringen.

Ready to give it a try? 

Intelligenter statt strenger schätzen

Eine einzelne Aufgabe sollte nicht mehr als 16 Stunden Arbeit in Anspruch nehmen. (Bei Verwendung von Story Points kannst du entscheiden, dass, sagen wir, 20 Punkte die Obergrenze sind.) Wenn einzelne Aufgabenelemente umfangreicher als das sind, lassen sie sich nur schwer zuverlässig abschätzen. Und Zuverlässigkeit ist vor allem für Elemente im oberen Bereich des Backlogs wichtig. Wenn für eine Aufgabe ein höherer Aufwand als der 16-Stunden-Schwellenwert (oder mehr als 20 Punkte) geschätzt wird, ist das ein Signal, diese Aufgabe weiter zu unterteilen und dann die Unteraufgaben erneut abzuschätzen.

For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change, and your application certainly will have changed. So prior estimates won’t be as accurate. Don’t waste time estimating work that is likely to shift. Just give the product manager a ballpark figure she can use to prioritize the product roadmap appropriately.

Aus früheren Schätzungen lernen

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time. 

Up Next
Metriken