Für Engineering-Teams

Ein technisches Briefing. Unterschiedlicher Wert auf jeder Ebene.

Dieselbe Evidenz hilft Product, die Arbeit zu definieren, Entwicklern, sie zu verstehen, und der Engineering-Leitung, sie zu planen. Nichts Wichtiges ist hinter einem Rollen-Tab verborgen.

GEMEINSAME GRUNDLAGEProblem · Aktuelles Verhalten · Wahrscheinliche Auswirkungen · Evidenz · Umfang · Fragen · Jira-Arbeit
01Product Owner

Technisch fundierte Arbeit ins Refinement bringen.

Die ursprüngliche Anfrage in einen prüfbaren Umfang verwandeln, bevor das gesamte Engineering-Team im Raum ist.

  • Fehlende Entscheidungen früher erkennen
  • Die Jira-Vorlage des Unternehmens verwenden
  • Wiederholte Klärungsgespräche reduzieren
  • Arbeit erstellen, die das Team hinterfragen und prüfen kann
02Entwickler

Mit bereits zusammengestelltem Systemkontext beginnen.

Jedem Entwickler, vom Junior bis zum Senior, einen konkreten Weg durch das aktuelle Verhalten und die wahrscheinlichen Auswirkungen geben.

  • Aktuelles Verhalten verstehen
  • Wahrscheinlich betroffenen Code und Services sehen
  • HTTP- und Kafka-Beziehungen verfolgen
  • Implementierung mit weniger versteckten Abhängigkeiten beginnen
03Tech Leads

Evidenz prüfen, statt sie zu rekonstruieren.

Codeverknüpfte Ergebnisse als Ausgangspunkt der technischen Prüfung verwenden und dabei Schlussfolgerungen und offene Fragen sichtbar halten.

  • Service-übergreifende Auswirkungen früher erkennen
  • Vorgeschlagene Änderungsbereiche hinterfragen
  • Architekturrisiken aufzeigen
  • Refinement auf Entscheidungen fokussieren
04Engineering Manager

Schätzungen weniger vom Gedächtnis abhängig machen.

Einen wiederholbaren Pre-Refinement-Schritt schaffen, statt sich auf die Person zu verlassen, die das System zufällig am besten kennt.

  • Untersuchung während Meetings reduzieren
  • Schätzungen bessere Grundlagen geben
  • Koordinationsrisiken früher erkennen
  • Systemwissen im Team verteilen
05CTO / VP Engineering

Pre-Refinement zu einer wiederholbaren Fähigkeit machen.

Eine Produktgrenze teamübergreifend verwenden: System lesen, Unsicherheit aufzeigen, Arbeit prüfen und anschließend in Jira erstellen.

  • Engineering-Verschwendung sichtbar machen
  • Qualität der Sprint-Eingaben verbessern
  • Abhängigkeit von wenigen Experten reduzieren
  • Dieselbe Methode über Repositories und Teams hinweg verwenden

Eine gemeinsame Grundlage für das Gespräch

Produktfragen und technische Evidenz bleiben im selben Briefing.

PRODUKTWas muss noch entschieden werden?
ENGINEERINGWas zeigt das aktuelle System?
AUSLIEFERUNGWelche Arbeit soll Jira erreichen?

Refinement auf Entscheidungen ausrichten

Jeder Rolle vor dem Refinement den benötigten Kontext geben.

RefineBrief anhand einer Java-Anfrage sehen, die Ihr Team bereits versteht.