Scrum nach Lehrbuch - mitten im Projektgeschäft
Product Backlog, Sprints, Events und Kennzahlen im Vokabular des Scrum Guide - und in demselben System, in dem Ihr Portfolio berichtet. Das Team arbeitet agil, die Organisation bleibt auskunftsfähig.
Wo Scrum auf dem Spektrum steht
Und welche Methoden in der Nachbarschaft liegen
Scrum: iterativ, empirisch, teamzentriert
Scrum steht am agilen Rand des Spektrums - kurze Zyklen, empirische Steuerung, selbstorganisierte Teams. In WORKSPACE.PM ist das keine Insel: Das Container-Konzept lässt agile und klassische Teilprojekte im selben Vorhaben nebeneinander arbeiten, und wer Fluss statt Timebox will, wechselt zu Kanban.
Woran Scrum neben dem Projektgeschäft zerreibt
Vier Muster aus Teams, die agil arbeiten - in Organisationen, die klassisch berichten
Zwei Werkzeuge, zwei Wahrheiten
Das Team arbeitet im Agil-Werkzeug, die Organisation fragt im PM-Tool nach - und dazwischen wird jede Woche von Hand kopiert.
Story Points treffen Statusbericht
Das Management will Prozente und Termine, das Team liefert Punkte und Sprints. Die Übersetzung bleibt an Ihnen hängen.
Events ohne Gedächtnis
Daily-Notizen im Chat, Review-Ergebnisse in Folien, Retro-Beschlüsse nirgends - nichts davon landet an der Arbeit selbst.
Backlog ist nicht gleich Backlog
Die Reihenfolge lebt in Köpfen und Tabellen. Wer nicht im Meeting war, priorisiert anders - und niemand merkt es.
Die Scrum-Anatomie - und was in WORKSPACE.PM dahintersteht
Sechs Elemente aus dem Scrum Guide, jedes mit dem Werkzeug, das es trägt.
Das Scrum-Team: drei Verantwortlichkeiten
Product Owner, Scrum Master und Developers teilen die Rechenschaft für das Produkt - ohne Hierarchie im Team.
Freie Rollen, eindeutige Verantwortung je Karte
Statt starrer Schablonen definieren Sie Rollen selbst - global und projektspezifisch, dazu Team-Rollen wie Teamleiter, Mitglied und Beobachter. Am Board gilt Scrum-Logik: genau eine verantwortliche Person je Karte, und nur sie kann zusagen oder ablehnen - serverseitig durchgesetzt.
Das Product Backlog
Die einzige, geordnete Quelle aller Arbeit am Produkt - ständig verfeinert und neu sortiert.
Eine geordnete Liste mit zehn Arbeitstypen
Die Backlog-Ansicht ordnet per Ziehen; der Rang wird serverseitig je Board geführt, die Sprint-Zuordnung geschieht im selben Zug. Zehn Work-Item-Typen von Epic über Story und Spike bis Tech-Debt, ein hierarchischer Etiketten-Baum und über-/untergeordnete Kartenverknüpfungen halten Ordnung im Bestand.
Refinement und Schätzung
Einträge werden geschnitten und geschätzt, bis sie in einen Sprint passen - in der Einheit, auf die sich das Team einigt.
Fünf Schätzeinheiten, vom Server durchgesetzt
Story Points nach Fibonacci (1-21) oder linear (1-10), T-Shirt-Größen von XS bis XXL, Stunden oder Tage: Die Einheit wird je Projekt festgelegt, und der Server erzwingt sie samt zulässiger Wertemenge bei jedem Anlegen und Ändern - keine gemischten Schätzungen im selben Backlog.
Der Sprint und seine Events
Eine feste Timebox mit vier Events: Sprint Planning, Daily Scrum, Sprint Review und Sprint-Retrospektive.
Timebox mit Terminserie, Agenda-Gedächtnis und Review-Notiz
Der Sprint wird angelegt und per Zug aus dem Backlog gefüllt. Das Daily läuft als Terminserie - offene Punkte wandern per Klick-Markierung automatisch auf die nächste Agenda. Der Abschluss ist geführt und hält die Review-Notiz am Sprint fest; für die Retrospektive stehen eine Wiki-Vorlage und anonyme Umfragen im Projekt-Feed bereit.
Sprint Backlog und Inspektion
Die Arbeit des Sprints ist jederzeit sichtbar - das Team inspiziert seinen Fortschritt anhand von Daten.
Sprint-Board plus eigene Metrik-Seite
Das Board filtert auf den Sprint - To Do, In Arbeit, In Review, Erledigt - mit zuschaltbarem Burndown direkt im Board. Die Metrik-Seite ergänzt Sprint-Burndown mit Idealkurve, Velocity über die letzten zehn Sprints samt Durchschnittslinie, Cumulative Flow, Cycle Time und die Sprint-Historie.
Empirie trifft Organisation
Scrum organisiert das Team - und die Organisation braucht weiterhin Termine, Budgets und Berichte.
Fortschritt aus Kanban, Bericht ohne Übersetzung
Teilprojekte messen ihren Fortschritt wahlweise „aus Kanban abgeleitet" - die Sprint-Arbeit speist damit direkt Ampeln, Statusberichte und das Portfolio, ohne dass jemand Punkte in Prozente übersetzt. Klassisch geführte Teilprojekte laufen im selben Dach mit.
Agil im Team, verlässlich nach oben
Scrum endet nicht an der Teamgrenze: Über die Fortschrittsmethode „aus Kanban abgeleitet" fließt Sprint-Arbeit ohne Umrechnung in Ampeln, Statusberichte und das Portfolio. So bleibt das Team im Takt - und die Organisation bekommt Antworten in ihrer eigenen Sprache.
Wo Scrum zu Hause ist
Projektwelten und Teams, in denen die Methode ihre Stärken ausspielt
Häufige Fragen zu Scrum in WORKSPACE.PM
Die Werkzeuge hinter Rollen, Artefakten, Events und Kennzahlen
WORKSPACE.PM bildet die Scrum-Anatomie ab: geordnetes Product Backlog, Sprints mit geführtem Abschluss, Sprint-Board mit Burndown und eine eigene Metrik-Seite. Welche Events Sie im System führen, entscheiden Sie - die Plattform folgt Ihrem Prozess. Die Methode lebt im Team, das Werkzeug trägt sie.
Rollen sind frei definierbar - Sie modellieren Product Owner und Scrum Master exakt so, wie Ihre Organisation sie lebt: global und projektspezifisch, in vier Berechtigungsstufen. Die Scrum-Logik steckt in den Mechaniken: Wer das Backlog ordnen darf, ordnet es; je Karte gibt es genau eine verantwortliche Person, und nur sie kann zusagen.
Das Sprint-Ziel erscheint als Widget direkt auf der Projektübersicht. Die Definition of Done führen Sie dort, wo das Team sie liest: als Wiki-Seite mit Verifizierungs-Siegel - und sichern sie je Karte über Checklisten ab. So bleibt die DoD sichtbar und gelebt.
Das Daily ist eine Terminserie mit Agenda: Offene Punkte einer Karte wandern per Klick-Markierung automatisch auf die nächste Agenda, das Protokoll verlinkt Karten und Personen. Für die Retrospektive stehen eine eigene Wiki-Vorlagen-Kategorie und anonyme Umfragen im Projekt-Feed bereit - und läuft die Retro als Termin, wandern ihre Maßnahmen als Aufgaben direkt ins Board.
Die Metrik-Seite bündelt die gemessene Wahrheit: Velocity der letzten zehn Sprints mit Durchschnittslinie, Sprint-Burndown mit Idealkurve, Cumulative Flow und Cycle Time - dazu die Sprint-Historie mit Review-Notizen. Damit trifft das Team seine Sprint-Entscheidungen auf Daten statt auf Bauchgefühl, so wie es die Empirie vorsieht.
Ja - über das Projekt-Dach: Mehrere agile Teilprojekte arbeiten neben klassischen im selben Vorhaben, jedes mit eigener Arbeitsweise, alle in einem Portfolio mit einem Berichtsweg. Teams, die Fluss statt Timebox wollen, wechseln je Teilprojekt zu Kanban - und methodisch breit aufgestellte Organisationen führen ein Vorhaben PMI-orientiert.
Verwandte Methoden
Wenn Ihr Team den Rahmen wechselt oder erweitert
Starten Sie den nächsten Sprint dort, wo Ihr Portfolio zuhause ist
Backlog anlegen, Einheit festlegen, Sprint füllen - in Minuten startklar.