Wir sind ein Team, dessen Hauptarbeit technisch, aber nicht in der Softwareentwicklung liegt, und wir verwenden Scrum seit einiger Zeit als unser Haupt-Framework (obwohl es wahrscheinlich ist, dass das, was wir tun, ScrumBut in verschiedener Hinsicht näher kommt) .
Vor diesem Hintergrund ist heute eine Frage in der Sprint-Planung aufgetaucht, auf die ich keine Antwort wusste – manchmal ist man bei der Arbeitsplanung versucht, einfach einige der Aufgaben zu erledigen, ohne sie in das Sprint-Backlog aufzunehmen. Entweder sind sie klein genug, dass es schneller geht, sie einfach zu erledigen, anstatt eine Jira-Aufgabe zu erstellen, oder die Aufgabe ist Teil des Planungsprozesses (z. B. eine kurze Recherche, um etwas zu verstehen, das geschätzt werden muss), aber die Ausführung führt natürlich in größere Arbeiten.
Gibt es eine Anleitung zum Erkennen, wann etwas auf die Tafel gelegt werden muss, anstatt nur auf die Seite gestoßen zu werden? Das Beste, was ich vorschlagen konnte, war: "Wenn Sie darüber nachdenken müssen, müssen Sie es wahrscheinlich an die Tafel setzen".
Nicht aufgeführte Aufgaben erhöhen den Kontextwechsel . Die Leute müssen sie im Hinterkopf behalten, aber sie vergessen. Dann erinnern sie sich mitten in einer anderen Aufgabe an sie und denken sich: „Ups, fast hätte ich es vergessen, aber ich muss es mir merken. Was habe ich noch vergessen?“. Das zieht Gehirnleistung von der eigentlichen Aufgabe ab. All dies kann sich mehrmals wiederholen, und am Ende des Tages fühlen Sie sich erschöpft, weil Sie häufig dazu übergehen, über diese kleinen Aufgaben nachzudenken .
Es ist einfach einfacher, für jede solche Aufgabe ein Ticket zu erstellen. Oder erstellen Sie 1 Ticket, in dem Sie alle kleinen Aufgaben als Aufzählungszeichen auflisten. Nachdem jemand eine der kleinen Aufgaben umgesetzt hat, kann er den Text einfach bearbeiten und ein kleines Häkchen neben die fertigen Elemente setzen.
Ob Sie es bei der Planung ignorieren, spielt keine so große Rolle. Wenn Sie bei Ihrer Planung schätzen - einfach schnell eine kleine Anzahl ins Feld stellen und weitermachen.
Hier gibt es zwei separate, aber verwandte Fragen.
Wie verbuche ich Arbeit, die Teil des Planungsprozesses ist?
Scrum berücksichtigt dies im Product Backlog Refinement. Die Teams, mit denen ich zusammenarbeite, haben in der Regel keine Probleme in Jira für Verfeinerungsarbeiten, es sei denn, die Arbeit wird intensiv sein. In jedem Sprint wird Einzelpersonen oder kleinen Gruppen Zeit eingeräumt, um sich die Arbeit ganz oben im Backlog anzusehen und mit dem Hinzufügen von Details zu beginnen. Labels ermöglichen es dem Team, nach Problemen zu filtern, die verfeinert oder besonders beachtet werden müssen (Entwicklung, UX, Produkt).
Bei sehr intensiver Arbeit, die etwas anderes als Aktualisierungen eines Jira-Tickets hervorbringt, kann dies als Spike bezeichnet werden, das als Jira-Problem verfolgt, einer oder mehreren Personen zugewiesen und die Ausgabe angehängt und überprüft wird.
Wie bewältige ich kleine Aufgaben?
Während der Verfeinerung kann die Person oder Gruppe, die an der Verfeinerung eines bestimmten Problems arbeitet, damit beginnen, Aufgaben hinzuzufügen. Anstatt Unteraufgaben oder separate Vorgänge in Jira zu verwenden, beginnen die Teams, mit denen ich arbeite, oft damit, die Arbeit innerhalb des ursprünglichen Vorgangs aufzuzählen. Bei Bedarf können Sie ein benutzerdefiniertes Feld verwenden, um einen speziellen Ort für diese Informationen hinzuzufügen, oder Sie können Plugins verwenden, die Funktionen wie Checklisten zu Jira-Vorgängen hinzufügen.
Manchmal wird die ursprüngliche Ausgabe in zwei getrennte Werkgruppen zerlegt. In diesem Fall würde ein neues Problem protokolliert und mit dem Original verknüpft. In anderen Fällen ist die Arbeit enger gekoppelt, kann aber auf mehrere Personen aufgeteilt werden. In diesen Fällen können Unteraufgaben nützlicher sein. Wenn die Arbeit wahrscheinlich von einer Person ausgeführt wird, kann sie einfach in der ursprünglichen Ausgabe selbst aufgeführt werden.
Am Ende geht es um die Balance. Mehr Probleme oder Unteraufgaben können die Sichtbarkeit erhöhen, aber es dauert auch etwas länger, die Probleme einzugeben und sicherzustellen, dass die Informationen in jedem einzelnen korrekt sind. Es ist ein Balanceakt, je nachdem, wer die Arbeit macht und was die Liefereinheit ist.
Entweder sind sie so klein, dass sie schneller erledigt werden können, anstatt eine Jira-Aufgabe zu erstellen
Gründe, warum Sie eine so kleine Aufgabe verfolgen möchten, sind unter anderem:
Das bedeutet nicht, dass Sie es verfolgen müssen, nur dass es sich lohnen kann, es zu verfolgen, wenn es einen ausreichenden Wert gibt.
oder die Aufgabe ist Teil des Planungsprozesses
Scrum geht davon aus, dass das Team bis zu 10 % seiner Zeit für die Vorbereitung auf die zukünftige Arbeit aufwendet. Eine kleine Aufgabe, die Teil des Planungsprozesses ist, passt in diese 10 % und ist daher bereits im Scrum-Ansatz berücksichtigt.
Es scheint wenig sinnvoll, eine solche Aufgabe zu verfolgen, es sei denn, Sie planen, eine Art Analyse Ihres Planungsprozesses durchzuführen.
Ich habe im Laufe der Jahre mehrere kleine Projekte für Apple durchgeführt, und so kann ich bezeugen, dass sie Poster an den Wänden haben (oder hatten ...) mit der Aufschrift : "Put it on the RADAR!"
("RADAR" ist das interne Managementsystem, das sie für fast alles verwenden.)
„Egal, wie du es machst, und egal, wie klein die Sache auch zu sein ‚scheint‘, steck eine Stecknadel durch [das arme Insekt …] und steck sie auf das Brett!“ Erlaube das nicht weder seine Existenz noch seine mögliche Bedeutung, um der offiziellen Aufmerksamkeit zu entgehen (selbst wenn Sie sich nie die Mühe machen, ihm „Stunden zu widmen“) .
Sicher, es ist in Ordnung, anfangs „eine Reihe von Aufzählungspunkten zu verwenden, sogar einen mit (sagen wir …) ‚FYI‘ , den Sie ständig ergänzen.“ Wenn irgendjemand zu einem späteren Zeitpunkt die Dinge neu ordnen muss, „so sei es“. Für jetzt: "Setzen Sie es auf das RADAR!"
Don Branson