Schlagwort-Archive: Scrum

User Story – Kundenanforderungen an Funktionalitäten korrekt definieren

Bitte bewerten Sie diesen Artikel!

Eine hohe Kundenorientierung ist im Marketing sowie im agilen Projektmanagement von besonderer Bedeutung. Schon immer gilt der Grundsatz „Der Kunde ist König“. Sie richten Ihr Produkt oder Ihre Dienstleistung an Ihrem Kunden aus und stellen diesen in den Fokus. Natürlich haben die Nutzer Ihres Produktes auch gewisse Ansprüche an die Funktionalität des Angebots. Es ist wichtig, dass Sie die Ansprüche Ihrer Kunden kennen und auch erfüllen können. Anhand der Erstellung einer User Story gelingt es Ihnen, diese Anforderungen der Nutzer an die Funktionalität Ihres Produktes präzise und anschaulich darzustellen. Welche weiteren Vorteile und Möglichkeiten sich Ihnen durch User Stories eröffnen, erfahren Sie in diesem Beitrag.

Definition – was ist eigentlich eine User Story?

User Story bedeutet übersetzt Anwendererzählung bzw. Nutzererzählung. Das heißt, die Anforderungen an ein Produkt werden aus der Sicht des Nutzers bzw. Verbrauchers beschrieben. User Stories sind Geschichten, die verdeutlichen, wie das Produkt verwendet werden soll. Somit ist die User Story ein zentrales Kommunikationstool zwischen Nutzern und Entwicklern. Sie dient dem gegenseitigen Verständnis und setzt den Kunden in den Fokus. Die erfassten Anforderungen beziehen sich auf die Funktionalität der Verwendung des Produktes und nicht auf die Art und Weise der Verwendung. Demnach geht es nicht um die konkrete Umsetzung, sondern lediglich darum, was das Produkt aus Verbrauchersicht „können“ bzw. welche Anforderungen es erfüllen muss.

Das Konzept der User Story stammt ursprünglich aus dem agilen Modell des Extreme Programming (XP). User Stories sind ein wichtiges Werkzeug in der agilen Softwareentwicklung und werden häufig im agilen Projektmanagement wie auch in Scrum genutzt. Scrum schreibt es zwar nicht vor, User Stories zu nutzen, dennoch sind diese oft im Product Backlog zu finden.

Prof. Dr. Michael Bernecker"Eine User Story bildet die Basis eines guten Anforderungsprofils an ein Produkt. Sie beschreibt die geforderte Funktionalität aus Sicht des Kunden und fasst somit die wichtigsten Ansprüche an das Entwicklungsteam kurz und präzise zusammen."

– Prof. Dr. Michael Bernecker, GF des Deutschen Instituts für Marketing

 

Bestandteile einer User Story

Konkret umfasst eine User Story einen Namen, eine kurze Erzählung und Akzeptanzkriterien. Die Erstellung kann formlos erfolgen oder anhand der folgenden Vorlage:

User Story

Die elementaren Bestandteile (User, Funktionalität, Nutzen und Akzeptanzkriterium) sollten jedoch in jeder User Story enthalten sein. Dabei werden die Fragen nach dem „WER“ [Nutzer], „WAS“ [Funktionalität] und „WARUM“ [Nutzen] durch die Nutzererzählung geklärt. Das „WIE“, also die Art und Weise der Umsetzung, ist dabei nicht von Bedeutung. Theoretisch ist der Autor Story natürlich der Nutzer, praktisch verfasst sie jedoch das Entwicklungsteam des Produktes. Die User Story wird nicht zwangsläufig vom Product Owner geschrieben, da oft das gesamte agile Entwicklungsteam dahintersteckt. Letztendlich ist es nicht von Bedeutung, wer die Nutzergeschichte schreibt, sondern, dass die Sicht des Nutzers bestmöglich repräsentiert wird.

Marketingleiter

Die drei C’s einer gelungenen User Story

Für eine gute User Story sollten Sie die drei C’s berücksichtigen, die ursprünglich von Ron Jeffries formuliert wurden:

1. Card

Jede Story wird auf einer kleinen (Papier)-Karte abgebildet, denn so können die Anforderungen nicht bis ins kleinste Detail beschrieben werden. Durch die Größe der Story Card, sind Sie dazu gezwungen, sich kurz zu halten. Idealerweise besteht die User Story nur aus ein bis zwei Sätzen. Die Story Card hat somit eine repräsentative Funktion.

2. Conversation

Die Card ist der Anfang eines Gesprächs (Conversation) und dient der Schaffung eines gemeinsamen Verständnisses, indem ganz einfach über die User Stories gesprochen wird. Das kann in Anforderungsworkshops, in der Schätzklausur bei Sprint Meetings zwischen Kunden und Projektmitgliedern sowie zwischen Projektmitgliedern oder zwischen Projektmitgliedern und Kunden erfolgen.

3. Confirmation

Jede User Story muss messbar bzw. testbar sein. So kann der Product Owner die Umsetzung der Einträge überprüfen. Aus diesem Grund wird auf der Rückseite der Story Card meistens das Akzeptanzkriterium (Confirmation) festgehalten.

Das Akzeptanzkriterium ist also nicht direkt Teil der eigentlichen User Story, muss jedoch immer mit festgehalten werden, um die Nutzergeschichte messbar zu machen. Das Akzeptanzkriterium wird, im Gegensatz zur tatsächlichen Story, nicht aus Sicht des Nutzers oder sogar direkt vom Nutzer formuliert, sondern durch den Anforderer bzw. Entwickler selbst. Demnach muss das Entwicklerteam festlegen, wie die korrekte Umsetzung gemessen und getestet werden kann. Das Akzeptanzkriterium definiert, zu welchem Zeitpunkt die User Story verwirklicht ist, indem es festlegt, welche Kriterien dafür erfüllt sein müssen. Dadurch definiert das Entwicklungsteam die Anforderungen, die erfüllt sein müssen, damit das Produkt auch von den Stakeholdern akzeptiert wird. Das bedeutet, die Anforderungen der Nutzer werden nochmals konkretisiert bzw. der Zeitpunkt, wann diese als erreicht gelten. Nachdem alle Akzeptanzkriterien festgelegt wurden, erfolgt ein Akzeptanztest, mit welchem die User Stories anhand verschiedener Testdurchläufe geprüft werden.

Seminar Agiles Marketing - Methoden und Tools

Sie möchten agile Methoden in Ihre Marketingprozesse implementieren? In unserem Seminar Agiles Marketing lernen Sie die wichtigsten Methoden und Tools agiler Marketingansätze kennen. Informieren Sie sich hier über konkrete Inhalte und sichern Sie sich jetzt einen Platz für das Seminar:

Die Basics zum agilen Projektmanagement gibt es in unserem Seminar Agiles Projektmanagement!

Tipps zur Erstellung einer guten User Story

Für eine zielführende User Story sollten Sie folgende Grundsätze beherzigen:

  • Knapp & Präzise!
    Achten Sie darauf, in kurzen Sätzen zu schreiben. Eine detaillierte Beschreibung der Anforderungen verfehlt den Sinn der User Story. Durch knappe Formulierungen können Sie die wesentlichen und wichtigsten Anforderungen konkretisieren und genau veranschaulichen.
  • Bleiben Sie einfach!
    User Stories sollten für alle Mitglieder des agilen Teams verständlich sein. Nutzen Sie also eine einfache Sprache beim Verfassen der Story und verzichten Sie auf Fachwörter, die von Teammitgliedern aus anderen Abteilungen nicht unbedingt verstanden werden.
  • In die Rolle des Users schlüpfen
    Nehmen Sie die Sicht des Nutzers ein und stellen Sie sich vor, Sie möchten das Produkt für einen bestimmten Zweck nutzen. Versuchen Sie, Ihren Kunden zu verstehen – nur so können Sie korrekt formulieren, welche Anforderungen der User tatsächlich an das Produkt stellt.
  • Mehrwert
    Versuchen Sie, einen echten Mehrwert und Nutzen zu formulieren. Nur so kann Ihr Entwicklungsteam auch konkrete Produkteigenschaften und Umsetzungsmöglichkeiten ausarbeiten. User Stories dienen der Kommunikation zwischen User und Entwickler – durch den Fokus auf den wesentlichen Nutzen bzw. Mehrwert, stärken Sie somit das Verständnis und tragen zu einer effizienteren Arbeit bei.
  • Die drei W’s
    Unabhängig davon, ob Sie Ihre User Story anhand einer Vorlage formulieren, sollte diese immer die drei W-Fragen beantworten – Wer möchte was und warum?
  • Ideen in User Stories formulieren
    Versuchen Sie, neue Anregungen, Ideen und Innovationen zuerst einmal in User Stories zu verpacken. Gelingt dies nicht, sollten Sie eventuell Ihre Idee noch einmal überdenken. Jede Produktinnovation sollte auf Ihren Kunden zugeschnitten sein, eine gewisse Funktionalität vorweisen und ihm einen Vorteil bzw. Nutzen liefern.

Unterschied zwischen Epic, Theme und User Story

Im agilen Projektmanagement kommen zudem häufig die Begriffe Epic und Theme vor. Sie fragen sich, was nun der Unterschied zwischen Epics, Themes und User Stories ist? Je nach Organisation werden diese Begriffe und deren Bestandteile teilweise unterschiedlich definiert und klassifiziert:

  • EPIC
    Prinzipiell stellt ein Epic eine große User Story dar und beschreibt die Anforderungen in einer detaillierteren Form. Ab welcher Größe ein agiles Team eine User Story als Epic klassifiziert ist unterschiedlich. Epics sind demnach größere Einheiten von Aufgaben und können in kleinere User Stories zerlegt werden.
  • THEMES
    Themes beschreiben tatsächlich nur Themen und Ideen des gesamten Unternehmens. Ein Theme stellt den Überbegriff mehrerer User Stories dar. Um ein Thema im Unternehmen abzuarbeiten, ist die Umsetzung mehrere Epics und sich daraus ergebender User Stories notwendig.

Weiterführende Nutzung von User Stories

User-Story-Mapping

Um Ihre User Stories bzw. Kundengeschichten nun richtig zu nutzen, kann das User-Story-Mapping für Sie von Vorteil sein. Die User Story Map skizziert die Customer Journey, also die Reise des Kunden mit dem jeweiligen Produkt. Demnach ist die User Story Map eine Übersicht über mehrere User Stories. Die Story Map ist viel ausführlicher und stellt die verschiedenen User Stories in ihren Details und Varianten grafisch dar. Mithilfe des Instruments der User Story Map können Sie einzelne Anwendergeschichten zu einem zweckdienlichen Modell zusammenfassen. Anhand dessen identifizieren Sie Anforderung-Leistung-Lücken und können Produktentwicklungen ganzheitlich planen, um einen echten Mehrwert für Ihre Kunden zu generieren.

Die grafische Darstellung einer User Story Map erfolgt nach dem Top-Down Ansatz und stellt die Anforderungen in einer Art Baumdiagramm zusammen. Das kann beispielsweise wie folgt aussehen:

User Story Mapping

Mehr zum User-Story-Mapping finden Sie hier.

Story Decomposition

Zur genaueren Ausführung der User Stories dient Ihnen auch die Story Decomposition. Dieser Begriff umfasst die detaillierte Beschreibung der User Story. Denn erst durch die Beschreibung des Mehrwerts bzw. Nutzens können auch die nachfolgende Umsetzung akkurat geplant und zielführende Entscheidungen getroffen werden.

Fazit: Warum machen User Stories Sinn?

Generell erleichtern User Stories die Kommunikation in agilen und interdisziplinären Teams. Die User Story verhilft allen Teammitgliedern zu einem besseren Verständnis der Kunden. Durch die knappe und präzise Formulierung werden die wichtigsten Anforderungen für jeden konkret offengelegt. Infolgedessen sind Anwenderwünsche leichter verständlich. Zudem schafft die User Story eine Brücke zwischen Nutzern und Entwicklern. So wird die Zusammenarbeit im agilen Projektmanagement gefördert.

Weiterhin können Sie mit diesem Konzept flexibel arbeiten und die Story an neue Veränderungen schnell anpassen. Die Nutzergeschichte stellt ein wichtiges Feedback dar und umfasst die Validierung und Bewertung diverser Nutzeranforderungen. So können Sie auch den Aufwand Ihrer Arbeit besser einschätzen.

Vor allem aber generieren Sie durch User Stories eine hohe Benutzer- bzw. Kundenorientierung, denn der Fokus liegt bei der Erstellung auf dem Kunden und seiner Sicht der Dinge. Das führt zu einem besseren Verständnis zwischen Anwendern und Entwicklern. Durch die schnelle und einfache Erstellung wird die User Story zu einem zentralen und sehr repräsentativen Mittel, um Wünsche und anwendungsbezogene Bedürfnisse der Kunden überschaubar darzustellen.

Die Umsetzung ist für die User Story zwar unerheblich, jedoch ergibt sich diese aus einer gut formulierten Story automatisch. Mithilfe der Nutzergeschichten wird der Kontext und der Wert verdeutlicht, was wiederum zu kreativeren Lösungen führt. Nur durch die Darstellung eines echten Mehrwerts bzw. Nutzens können die Anforderungen an die Produktfunktionalität optimal geplant und umgesetzt werden.

Das DIM als Ihr Partner im agilen Projektmanagement

Sie brauchen Hilfe, um User Stories erfolgreich in Ihrem agilen Team zu implementieren?

Unsere erfahrenen Experten helfen Ihnen gerne! Kontaktieren Sie uns für ein persönliches Beratungsgespräch:

Bastian FoersterBastian Foerster

Tel.: +49 (0)221 - 99 555 10 16
Fax: +49 (0)221 - 99 555 10 77
E-Mail senden

#UserStory #Userstorymap #UserStories #Agil #AgilesProjektmanagement #Card #Conversation #Confirmation #Scrum #Epic #Themes

Mit Scrum erfolgreich zum agilen Projektmanagement

Mit Scrum erfolgreich zum agilen Projektmanagement
5, 1 Bewertungen

Sie möchten in Ihrem Unternehmen agiles Projektmanagement einführen? Sie suchen nach einer geeigneten Methode? Oder Sie haben schon von Scrum gehört, aber noch keine genaue Vorstellung davon? Erfahren Sie, wie Scrum funktioniert und wie Sie damit Ihr Projekt sicher ins Ziel führen.

Was ist Scrum?

Scrum ist eine agile Methode der Teamarbeit. Die Teammitglieder arbeiten nach festgelegten Regeln eigenverantwortlich zusammen und stimmen ihre Arbeitsergebnisse schrittweise in kurzen Zeitabschnitten untereinander ab. So fokussieren Sie sich auf schnelle Umsetzung und dynamische Prozesse. Dazu zerlegen Sie die Komplexität Ihres Projekts, in dem Sie es in kleinere Einheiten herunterbrechen und sich wiederholende Arbeitsprozesse solange fortführen, bis das Projektziel erreicht ist. Wesentliche Teile der Projektanforderungen und mögliche Lösungsansätze bleiben zu Beginn bewusst unklar. Anstatt mit starren und detailgenauen Lasten- und Pflichtenheften, arbeitet das Scrum-Team in sogenannten Sprints nach dem Prinzip von Transparenz, Abgleich und Anpassung.

Für welche Projekte eignet sich die Methode?

Ursprünglich stammt Scrum aus dem Bereich der agilen Softwareentwicklung. Von daher liegt nah, dass sich das Tool besonders für die Entwicklung von innovativen Produkten oder Dienstleistungen eignet. Vor allem, wenn Sie noch nicht so genau wissen, was und wie etwas am Ende herauskommen soll. Prinzipiell ermöglicht Ihnen diese Methode jedoch auch, anders gelagerte Projektaufgaben anzugehen. Drei Begriffe stehen im Fokus: Rollen, Artefakte und Ereignisse. Rollen differenzieren die einzelnen Funktionen der Teammitglieder. Artefakte unterstützen, um Anforderungen und Arbeitsergebnisse zu dokumentieren. In Scrum kommt das Team in regelmäßigen Zeitabschnitten zusammen. Dabei plant es die Projektschritte, bespricht noch abzuarbeitende bzw. erledigte Aufgaben. Retrospektiv schaut das Team, welche potenziellen Verbesserungen sich im Ablauf und der Zusammenarbeit ergeben haben. Diese Zusammenkünfte nennt man Ereignisse.

Scrum

Die drei Scrum-Rollen

Ein Scrum-Team besteht aus den folgenden drei Rollen:

  • Product Owner
  • Entwicklungsteam
  • Scrum Master

Als Product Owner verantworten Sie in Scrum-Projekten den Produkterfolg. Sie stehen sowohl für die Nutzer des Produktes als auch für die Stakeholder. Also für alle, die Interessen am Produkterfolg haben. In dieser Rolle entscheiden Sie über die Eigenschaften des Produktes. Sie priorisieren die Vorgehensweise und erläutern Ihrem Entwicklerteam die notwendigen Schritte. Sie halten regelmäßig Rücksprache mit den Stakeholdern. So eruieren Sie iterativ, welche Bedürfnisse und Wünsche existieren. Diese Erkenntnisse tragen Sie dann in Ihr Scrum-Team. Wichtig: Formulieren Sie Anforderungen möglichst aus der Anwendersicht.

Die Größe des Entwicklungsteams ergibt sich abhängig von den Anforderungen. Es sollten mindestens drei aber höchstens neun Mitglieder sein. Die Spanne muss alle benötigten Kompetenzen abdecken, den Koordinierungsaufwand jedoch in Grenzen halten. Das Team liefert dem Product Owner die von ihm gewünschten Produktfunktionalitäten in der von ihm festgelegten Reihenfolge. Es verantwortet zudem die Einhaltung vereinbarter Qualitätsstandards. Dabei organisiert sich in Scrum-Projekten das Entwicklungsteam selbst und arbeitet interdisziplinär.

In der Rolle als Scrum Master sorgen Sie zugleich als Coach dafür, dass Scrum funktioniert und gelingt. Sie arbeiten mit dem Entwicklungsteam zusammen, ohne aber selbst dazuzugehören. Sie erläutern die Regeln, überprüfen, ob sie eingehalten werden und kümmern sich, wenn Probleme auftreten. Etwa in Form mangelnder Kommunikation oder gestörter Zusammenarbeit. Als Scrum Master geben Sie allerdings keine Arbeitsanweisungen und besitzen keinerlei disziplinarische Handhabe.

Agiles Marketing Seminar

Lernen Sie agile Methoden und Tools für Ihr Marketing kennen und erfahren Sie, wie die erfolgreiche Umsetzung in Ihrem Unternehmen gelingen kann. Mehr zu den Inhalten und Terminen:

Die drei Scrum-Artefakte

Um den Projektfortschritt für alle Beteiligten transparent zu steuern und zu dokumentieren, nutzen Sie drei sogenannte Artefakte:

  • Product Backlog
    Hier versammeln sich sämtliche Eigenschaften und Funktionen, die das Produkt haben soll. Zu Projektbeginn stellt sich die Liste eher grob dar. Durch regelmäßigen Austausch zwischen Stakeholdern, Product Owner und Entwicklungsteam, gestaltet sich das Product Backlog im Projektverlauf immer detaillierter.
  • Sprint Backlog
    Anstehende Aufgaben und Anforderungen notiert das Team im Sprint Backlog. Diese arbeitet das Entwicklungsteam in einem vorgegebenen Zeitintervall, dem Sprint, ab. Ein Sprint in Scrum-Projekten dauert max. 4 Wochen, üblicherweise 14 Tage.
  • Product Increment
    Das am Ende eines Sprints erzielte Teilergebnis nennt man Product Increment. In diesem Zwischenstadium sind alle bis dahin umgesetzten Arbeiten der vorangegangenen Sprints enthalten. Wichtig: Am Ende eines jeden Sprints muss das vorliegende Inkrement als "Done" bewertet sein.

Die vier Scrum-Ereignisse

Ein Scrum-Prozess verläuft in Ereignissen, die festen Zeitfenstern (Timebox) folgen. Man unterscheidet vier Ereignisse:

  • Sprint Planning
    Hier legt das Scrum-Team fest, welche Aufgaben im nächsten Sprint wie erledigt werden sollen. Dieses Sprint-Ziel ergibt sich aus den Einträgen im Product Backlog und den vom Product Owner gesetzten Prioritäten. Außerdem: an der Stelle formuliert das Team klar, wann eine Aufgabe als erledigt gilt und ein Teilergebnis (Product Increment) als „Done“ klassifiziert wird.
  • Daily Scrum
    In täglichen Zusammenkünften von etwa 15 Minuten berichtet jedes Teammitglied, was es seit dem letzten Daily Scrum erledigt hat. Und was es bis zum nächsten Daily Scrum noch zu tun gibt. Auch berichtet es von etwaigen Arbeitsbehinderungen. Hier unterstützt der Scrum Master, die vorliegenden Störungen zu beseitigen. Auf dem „Sprint-Burndown-Chart“ wird der Projektstatus sichtbar und, ob sich das Team noch im vorgegebenen Zielkorridor befindet.
  • Sprint Review
    Zum Abschluss eines Sprints stellt das Team im Review dem Product Owner Ergebnisse und Teil-Produkte vor. Dieser prüft, ob die vereinbarten Kriterien eingehalten wurden und der Definition „Done“ entsprechen. Fällt seine Überprüfung positiv aus, gilt das Sprint-Ergebnis als abgenommen. Der Eintrag im Sprint Backlog kann abgehakt werden. Hierdurch aktualisiert sich zugleich der Product Backlog. Dieser Prozess wiederholt sich bis zur abschließend fertigen Produktentwicklung.
  • Sprint-Retrospektive
    Sie unterstützt den Lernprozess für künftige Projekte. Dazu tauschen sich zwischen einem Sprint Review und dem nächsten Sprint Planning die Teammitglieder aus. Diskutiert werden bspw. Aspekte wie Zusammenarbeit, Abläufe oder Kommunikation. Das Team hält fest, was für den nächsten Sprint verbessert werden sollte.
Marketingleiter

Fazit

Agile Methoden übertreffen nachweislich klassische Ansätze im Projektmanagement hinsichtlich des Projekterfolgs. Als Anwender sollten Sie dennoch berücksichtigen, dass die Methode von Menschen angewendet wird. Erfahrungen aus der Praxis zeigen, dass sich die Lehrbuchversion nicht immer 1:1 auf jedes Projekt anwenden lässt. Nutzen Sie das Tool, dann liegen folgende zehn Vorteile von Scrum auf Ihrer Seite:

  1. Sie reduzieren Komplexität, in dem Sie Ihr Projekt in kleine Einheiten zerlegen.
  2. Sie fokussieren sich auf relevante Produkteigenschaften und die zu erledigenden Aufgaben.
  3. Sie nehmen Änderungswünsche und neue Entwicklungen rechtzeitig auf.
  4. Sie treiben Ihr Scrum-Projekt in dynamischen Schritten „in time“ zum Ziel.
  5. Sie steuern und dokumentieren kontinuierlich und transparent.
  6. Sie erkennen schnell Fehlentwicklungen und reagieren frühzeitig auf Störungen.
  7. Sie halten alle Beteiligten zeitnah im gegenseitigen Austausch.
  8. Sie sorgen dafür, dass alle im Scrum-Team wissen, was sie bis wann zu tun haben.
  9. Sie fördern eine sich selbstorganisierende und interdisziplinäre Arbeitsweise.
  10. Sie lernen gemeinsam für Ihr nächstes Scrum-Projekt.

Sie möchten agile Methoden in Ihrem Unternehmen umsetzen?

Kontaktieren Sie uns für ein persönliches Beratungsgespräch!

Bastian FoersterBastian Foerster

Tel.: +49 (0)221 - 99 555 10 16
Fax: +49 (0)221 - 99 555 10 77
E-Mail senden

#Scrum #AgilesProjektmanagement #Agilität #AgileMethode

Product Owner – Welche Rolle spielt er im Produktmanagement?

Product Owner – Welche Rolle spielt er im Produktmanagement?
4.5, 11 Bewertungen

Die Rolle des Product Owners stellt eine verantwortungsvolle und wichtige Position innerhalb des Entwicklungsprozesses im agilen Projektmanagement dar. Der Product Owner steht dabei in Beziehung zu allen Projektbeteiligten und muss verschiedene Aufgaben gewissenhaft umsetzen sowie bestimmte Fähigkeiten innehaben. Was ein Product Owner genau macht, erklären wir im folgenden Beitrag.

Was ist ein Product Owner?

Der Product Owner ist meist der Leiter der Produktentwicklung, der Geschäftsführer oder hat eine andere hochrangige Position im Unternehmen. Im Rahmen von Scrum, einer der bekanntesten Vorgehensweisen im agilen Projektmanagement, besitzt er die Autorität, alle Entscheidungen bezüglich der Produktentwicklung zu treffen. Doch auch wenn er über die Anforderungen und Vorgehensweise des Produktes bestimmt, berücksichtigt er die Vorschläge des Entwicklungsteams und der Stakeholder. Er ist allein dafür verantwortlich, die Entwicklung und Einführung des Produkts erfolgreich umzusetzen. Ein Product Owner arbeitet vor allem mit dem Product Backlog. In diesem sind alle Arbeitspakete aufgelistet, die vom Entwicklungsteam umgesetzt werden müssen. Der Product Owner trägt dabei die Entscheidung, wie die Arbeitspakete zu priorisieren sind.

Product Backlog

Beziehungen des Product Owners

Product Owner und Entwicklungsteam

Ein Product Owner muss dafür sorgen, dass das Entwicklungsteam genau versteht, wie ihre Arbeitspakete aussehen und ob die schon abgeschlossenen Arbeitspakete das gewünschte Ziel erreicht haben. Außerdem gehört es zu den Aufgaben des Product Owners, dem Team Hilfe zu leisten.

Product Owner und Stakeholder

Ein Product Owner bezieht die Stakeholder mit in seine Arbeit ein, indem er ihre Bedürfnisse erkennt und die Arbeitspakete dementsprechend priorisiert. Zudem stellt der Product Owner den Kontakt zwischen dem Entwicklungsteam und den Stakeholdern her. Durch diesen direkten Kontakt bekommt das Team die Möglichkeit, die Wünsche der Produktnutzer besser zu verstehen. Für die Kommunikation mit den Stakeholdern sowie mit dem Entwicklungsteam benötigt der Product Owner ausgeprägte Kommunikationsfähigkeiten.

Product Owner und höheres Management

Das höhere Management, das nicht direkt für das Produkt zuständig ist, sollte dem Product Owner die Verantwortung für den Erfolg des Produkts übertragen, d.h. er sollte die Transparenz der Entwicklungsschritte gewährleisten und die Aufgaben des höheren Managements umsetzen.

Product Owner und Scrum Master

Die Beziehung zwischen dem Prodcut Owner und dem Scrum Master zeichnet sich dadurch aus, dass der Scrum Master ihn in allen Belangen bezüglich seiner Arbeit coacht. Egal, ob es um Herausforderungen, Sorgen oder Fragen geht. Ein Scrum Master beobachtet den Product Owner bei seiner Arbeit und kann ihm Rückmeldung geben und ihn damit sowohl menschlich als auch fachlich unterstützen.

Lehrgang Produktmanager

Fähigkeiten und Aufgaben eines Product Owners

Um als Product Owner erfolgreich agieren zu können und mit dem Entwicklungsteam sowie mit den Stakeholdern souverän umgehen zu können, muss er verschiedene Fähigkeiten besitzen und Aufgaben professionell umsetzen.

  • Vision vermitteln: Ein Product Owner muss in der Lage sein, dem Entwicklungsteam die Vision des Produkts zu vermitteln. Dadurch kann sich das Team besser in die Kunden hineinversetzen und sich auf das Wesentliche konzentrieren.
  • Probleme lösen: Im Falle eines Problems erarbeiten der Product Owner und das Team gemeinsam verschiedene Lösungsvorschläge mit entsprechenden Vor- und Nachteilen. Der Product Owner gibt dem Team keine Lösungsansätze vor, um der Motivation der Produktentwickler nicht zu schaden.
  • Input managen: Wie schon erwähnt, können Stakeholder ebenfalls ihre Vorschläge und Wünsche einbringen. Ein Product Owner muss dafür sorgen, dass diese transparent für alle Beteiligten sind und diskutiert werden.
  • Transparenz schaffen: Da ein Product Owner die Entwicklungsschritte eines Produkts überprüfen muss, kontrolliert und aktualisiert er nach jedem Arbeitspaket, wie zügig das Team arbeitet und wie viel Arbeit noch erledigt werden muss. Der Product Owner kann dann die Arbeitspakete entsprechend anpassen.
  • Prioritäten setzen: Ein Product Owner kann, wie schon erwähnt, die Arbeitspakete im Product Backlog selbst priorisieren. Er kann sich dabei auf verschiedene Modelle stützen oder auf Informationen, die ihm zur Verfügung stehen.

Verantwortung des Product Owners aus der Sicht von SCRUM

Der Produkt Owner hat zusammenfassend Verantwortung über die folgenden Punkte:

  • Den wirtschaftlichen Erfolg seines Produktes
  • Die Kommunikation mit den relevanten Stakeholdern
  • Den Leistungsumfang und den Liefertermin des Produktes
  • Die Priorität und die Umsetzung von Produkt Backlog Items
  • Die Berücksichtigung von Customer Insights bei der Gestaltung des Produktes

Das wesentliche Instrument des Produkt Owners ist das Product Backlog. Dort werden die umzusetzenden Produktmerkmale transparent priorisiert und dem Team zur Verfügung gestellt.

 

Product Owner – Fazit

Product Owner haben eine hochrangige und verantwortungsvolle Position inne. Sie müssen verschiedene Fähigkeiten besitzen, um die Produktentwickler zu motivieren und müssen dafür sorgen, dass sie ein umfangreiches Verständnis für ihre Arbeit aufbringen. Sie müssen mit den Stakeholdern professionell und souverän umgehen können und diese mit dem Entwicklungsteam vernetzen. Der Scrum Master steht dem Product Owner dabei zur Seite und unterstützt ihn im Hinblick auf Fragen oder bevorstehenden Herausforderungen.

Das agile Marketing-Meeting – 10 Tipps für mehr Effizienz in Meetings!

Bitte bewerten Sie diesen Artikel!

Jetzt mal ganz ehrlich, wie viele Stunden haben Sie schon in Meetings verbracht und haben sich anschließend gedacht: was für eine Verschwendung! Was mach ich hier eigentlich? Musste das sein?

Fast jedem ergeht es so und trotzdem sind wir auf Meetings angewiesen. Das muss nicht so sein! Und was ist der Schlüssel zu einer produktiven Besprechung statt Zeitverschwendung? Organisation. Mit einer effizienten Gestaltung eines Marketing-Meetings lässt sich die Anzahl der Besprechungen, die unproduktiv sind und kein Mehrwert liefern, reduzieren. Denn die Optimierung Ihrer Besprechung wirkt sich nicht nur positiv auf Teams aus, sondern sogar auf die gesamte Organisation.

Wir sind immer auf der Suche nach Möglichkeiten, um den Wert der von uns veranstalteten Marketing-Meetings zu verbessern. Wir haben für Sie 10 einfache, aber effiziente Tipps zusammengestellt, die Ihnen dabei helfen, Ihre nächstes agile Meeting zu planen und erfolgreicher zu gestalten. Hier sind unsere 10 Lieblingstipps.

Meeting-Tipp Nr. 1: Warum muss das Meeting eigentlich sein

Fragen Sie sich, warum Sie das Meeting abhalten. Liegt es daran, dass Sie es immer haben? Ist es notwendig oder hat es seinen Nutzen oder Zweck überlebt? Eine abgesagte Besprechung ist viel besser als eine, bei der alle Zeit verlieren. Nur wenn Sie ein wirkliches Ziel haben, können Sie ihr Marketing-Meeting auch effizient gestalten. Mit unserem Workshop Canvas planen wir zumindest besondere Workshops & Marketing-Meetings.

Workshop Canvas

Meeting-Tipp Nr. 2: Laden Sie die richtigen Personen zum Meeting ein

Weniger ist mehr, wenn es um Meetings geht: Sie müssen nicht jeden einladen. Meetings sind teuer und blockieren oftmals produktive Ressourcen. Je mehr Teilnehmer ein Meeting hat, um so unproduktiver wird es. Fragen Sie sich, warum jeder Mensch da ist und welche Rolle er spielt. Wenn sie keine Rolle haben oder wenn ihre Rolle von einer besser geeigneten Person wahrgenommen wird, laden Sie sie nicht ein (wahrscheinlich werden sie sich bei Ihnen bedanken). Laden Sie sich selber auch nicht zu jedem Meeting ein. Es sei denn Sie wollen eine aktive Rolle spielen und sich einbringen. Wenn wichtige Entscheidungsträger oder Stakeholder es nicht zu Ihrer Besprechung schaffen, sollten Sie eine Verschiebung in Betracht ziehen. Es hat keinen Sinn, eine Besprechung abzuhalten, um sie erneut durchzuführen, wenn alle verfügbar sind.

Meeting-Tipp Nr. 3: Geben Sie an, welche Art von Besprechung Sie haben

Es gibt unterschiedliche Arten von Besprechungen. Klären Sie vorher um welche Art von Meeting es sich handelt. Dann ist der Ablauf auch klar und Beteiligte können sich darauf optimal vorbereiten.

Prinzipiell gibt es folgende Besprechungen:

  • Regelmäßige Besprechungen mit kleiner Teilnehmeranzahl
  • Formelle Meetings mit einer großen Teilnehmerzahl
  • Ad-hoc Besprechungen mit kleiner Teilnehmerzahl

Man kann natürlich auch noch Check-in / Check-up Mettings, Projekt-Status-Meetings, Steuerungs-Meetings und Strategie-Meetings unterscheiden. Egal welche Terminologie Sie haben, machen Sie nur allen Teilnehmern vorher transparent, um was für ein Meeting es sich handelt.

Meeting-Tipp Nr. 4: Fügen Sie der Besprechungseinladung eine Tagesordnung hinzu

Eine Agenda ermöglicht es den Menschen, sich auf das Meeting vorzubereiten, anstatt erst im Meeting sich auf das Thema einzulassen. Die meisten Menschen bevorzugen eine klare Struktur in Meetings. Dabei sollte natürlich auch die TIME-BOX, also die Meetingdauer klar sein.

Wir finden diese Strukturabbildung sehr hilfreich. Statten Sie alle Meetingräume damit aus. Dann geht es einfacher!

Team

PS: Danke an das Team von YouMagnus  für die Abbildung.

Meeting-Tipp Nr. 5: Machen Sie sich gemeinsam Notizen

Wenn jeder seine eigenen Notizen macht, kann dies zu Verwirrung führen, da jeder Teilnehmer möglicherweise andere Dinge hört und für wichtig erachtet. Machen Sie sich stattdessen gemeinsam Notizen. Wir arbeiten zum Beispiel mit Collaborationslösungen wie Nureva SPAN, Microsoft OneNote und Microsoft Tasks in den verschiedenen Meetingsituationen. Damit stellen wir sicher, dass jeder im Meeting direkt sieht was notiert wird und jeder erhält direkt ein (digitalbasiertes) Protokoll. Damit sind

(I) Informationen,

(E) Entscheidungen und

(A) Aufgaben für jeden transparent.

Für wiederkehrende Besprechungen (z.B. Daily SCRUM Meeting) benutzen wir dasselbe Dokument. So kann man immer wieder auf die Besprechungsinfos der Vergangenheit zugreifen. Die neuesten Inhalte werden immer an den Anfang des Dokumentes gesetzt.

Kleiner Tipp: Oft wird die Rolle des Protokollschreibens an Frauen delegiert. Das ist ein No-Go! Lassen sie die Protokollschreiber-Rolle rotieren. Das Aufnehmen von Notizen sollte eine gemeinsame Verantwortung sein.

Meeting-Tipp Nr. 6: Beginnen und enden Sie pünktlich (Timeboxing)

Es gibt unzählige Gründe, warum Meetings zu spät beginnen, aber es kommt viel zu oft vor. Verspätete Besprechungen in den frühen Morgenstunden können zu einem Kaskadeneffekt führen, der sich auf den Zeitplan aller Teilnehmer für den Rest des Tages auswirkt. Respektieren Sie Ihre Kollegen, indem Sie pünktlich beginnen und pünktlich enden.

Meeting-Tipp Nr. 7: Beenden Sie das Meeting mit einem Zeitfenster, um den Maßnahmenplan zu klären

Beenden Sie ein Meeting nicht, ohne zuvor Aktionselemente festgelegt zu haben. Wenn Sie am Ende des Meetings Zeit haben, um Aktionen festzulegen und Verantwortungen zuzuweisen, dann haben Sie ein direktes Commitment von den Teilnehmern. Der Microsoft Planner ist sehr gut geeignet, um direkt die Aufgaben transparent zuzuordnen, mit Prioritäten und Zuständigkeiten auszustatten.

Meeting-Tipp Nr. 8: Schalten Sie die Kameras standardmäßig ein, einschließlich der Personen, die sich mit Ihnen im Raum befinden

Hybride Meetings sind immer häufiger an der Tagesordnung und bieten Vorteile. Zeitersparnisse, weniger Reisezeiten und Reisekosten und im Zeitalter von standortübergreifenden Teams ein echte Alternative. Nutzen Sie moderne Tools wie Zooms oder Microsoft Teams und schalten Sie immer die Kameras ein. So sind die Teilnehmer auch immer mit dabei und niemand kann sich „ausklinken“.

Meeting-Tipp Nr. 9: Wirkung statt Output

Wenn Sie regelmäßige Besprechungen mit demselben Team führen, finden Sie heraus, wie Sie gemeinsam mehr Wirkung entfalten. Es geht nicht darum möglichst viele Aktivitäten in einem Meeting zu produzieren. Es sollten sich auf die reduziert und fokussiert werden, die auch eine Wirkung produzieren.

Wir finden den Mobius Loop hier ganz hilfreich.

Meeting-Tipp Nr.10: Überprüfen Sie den Wert des Meetings und suchen Sie nach Verbesserungsmöglichkeiten

Die gesamten Tipps helfen nur, wenn Sie auch richtig umgesetzt werden. Überprüfen Sie regelmäßig Ihre Meetings im Marketing und Vertrieb. Macht das Sinn? Sind die Meetings wertvoll? Sind wir alle mit dem Outcome zufrieden?

Ein einfaches Feedback erhalten wir durch eine Stimmungsabfrage. Wie geht es den einzelnen, was ist für ihn/ Sie gut und was können wir tun, um die Situation zu verbessern.

Sie möchten sich oder Ihre Mitarbeiter im Bereich Marketing und Vertrieb weiterbilden? Nehmen Sie Kontakt mit unserem Weiterbildungsexperten auf!

Jonas Gran

Herr Jonas Gran

Tel.: +49 (0)221 - 99 555 10 17
Fax: +49 (0)221 - 99 555 10 77
E-Mail senden

Seminar Agiles Marketing - Methoden und Tools

Sie möchten in Ihrem Unternehmen agile Marketingmethoden erfolgreich umsetzen? Dann ist unser Seminar Agiles Marketing - Methoden und Tools das richtige für Sie! Informieren Sie sich jetzt über die genauen Termine und die Inhalte:

Fazit

Schlechte Marketing-Meetings kosten Zeit, sind ineffizient und haben negative Auswirkungen auf das Arbeitsklima. Trotzdem bleiben Besprechungen fester Bestandteil des Arbeitsalltags und sind wichtig für interne Abstimmungen, Ideenkreation sowie Aufgabenverteilungen und sollten daher gut organisiert und strukturiert sein.

Wie? Schon 10 Tipps fertig? Wir könnten noch weitere nennen. Doch welche Erfahrungen haben Sie gemacht? Was wäre Ihr Lieblingstipp für bessere Meetings? Nutzen Sie doch das Kommentarfeld für mehr Tipps, um auch im Jahr 2020 mehr Perfomance hinzubekommen.

#meeting #arbeitssorganisation #produktivität #effizienz

Das Product Backlog – Wie Sie Ihr agiles Projekt organisieren

Das Product Backlog – Wie Sie Ihr agiles Projekt organisieren
5, 1 Bewertungen

Das Product Backlog ist eine zentrale Praktik, die insbesondere im agilen Projektmanagement Anwendung findet. Dabei geht es um die Entwicklung eines Produktes auf der Basis hoher Flexibilität und Anpassung. Bei optimalem Einsatz des Product Backlogs wird die Bearbeitung von Kundenaufträgen signifikant erleichtert.

1. Anwendung eines Product Backlogs

Das Product Backlog wird hauptsächlich im agilen Projektmanagement (zum Beispiel Scrum) eingesetzt. Scrum gilt als Rahmenwerk, innerhalb dessen unterschiedliche Prozesse und Techniken angewendet werden. Ziel der Scrum-Methode ist die Entwicklung eines Produktes mit höchstmöglichem Wert. Das Product Backlog ist eine geeignete Methode zur schnellen und optimalen Zielerreichung, denn im darin wird die ausstehende Arbeit festgehalten, die zur Produktentwicklung notwendig ist. Zudem werden in dem Dokument Kundenbedürfnisse untersucht, Aufgaben der Markteinführung festgelegt und Fehler identifiziert, um diese schnellstmöglich beseitigen zu können.

Projektmanagement Seminar

Lernen Sie im Projektmanagement Seminar Methoden und Instrumente für agiles Projektmanagement kennen. Im Fokus steht der Transfer des erlernten Wissens in die Praxis des Projektmanagers und seines Teams. Informieren Sie sich über die Inhalte des Seminars:

2. Die 5 Eigenschaften des Product Backlogs

Verantwortlich für das Product Backlog ist der Product Owner. Er sollte das Dokument kontinuierlich an die geänderten Bedingungen anpassen. Dabei gilt es, die folgenden Eigenschaften einzuhalten, um eine optimale Nutzung des Product Backlogs sicherzustellen.

2.1 Adäquat detailliert

Das Product Backlog muss angemessen detailliert sein. Dabei stellt sich die Frage: Was bedeutet angemessen? Wie detailliert ein Eintrag sein soll, ist abhängig von der Position des Eintrags im Product Backlog, was wiederum vom Grad der Priorisierung abhängt. Es gilt: Je höher die Priorität des Eintrags ist, desto weiter oben befindet sich der Eintrag im Product Backlog. Zudem gilt, dass der Detaillierungsgrad der Einträge abnimmt. Somit werden hochpriorisierte Einträge sehr detailliert abgebildet und niedrigpriorisierte Einträge nur grob skizziert. Schließlich müssen Einträge, die im nächsten so genannten Sprint (regelmäßige und wiederholbare Arbeitsabläufe) bearbeitet werden sollen, detaillierter dargestellt werden, als vage Ideen, die sich am Ende des Product Backlogs befinden. Durch diese Eigenschaft wird das Product Backlog insgesamt kurz und knapp gehalten. Während des gesamten Projektverlaufs werden Anforderungen identifiziert und verfeinert.

2.2 Abgeschätzt

Das Abschätzen der Product Backlog Einträge hilft dabei, die ungefähre Größe der Anforderung auszudrücken. Dies ist hilfreich, um die Einträge zu priorisieren und den Projektfortschritt zu verfolgen. Die Abschätzungen der Einträge finden normalerweise regelmäßig im Sprint statt, da neue Einträge abgeschätzt und die Abschätzung bestehender Einträge angepasst werden muss.

2.3 Veränderlich

Das Product Backlog ist kein Dokument, das zu Beginn des Projektes erstellt wird und dann final ist. Es wird kontinuierlich an die aktuellen Bedingungen angepasst. Dazu zählt unter anderem das Hinzufügen neuer Einträge, die Veränderung der Reihenfolge der Einträge, das Entfernen sowie die Modifizierung und Verfeinerung bestehender Einträge. Wie stark sich das Product Backlog über den Projektverlauf hinweg verändert, wird durch den Innovationsgrad des Produktes beeinflusst. Die Veränderungen des Backlogs werden nicht nur durch das eigene Scrum-Team angestoßen, auch das Feedback der Kunden, Anwender und anderer Interessenvertreter bietet Anpassungsmöglichkeiten des Product Backlogs.  Durch die agilen Prozesse werden Anforderungen sehr zeitnah in Produktinkremente (Ergebnis eines Sprints) umgesetzt. Dies ermöglicht das regelmäßige Einholen von Feedback und die anschließende Einarbeitung ins Product Backlog. Dadurch wächst und verändert sich das Product Backlog ständig.

Product Backlog

2.4 Priorisiert

Die Einträge werden nach ihrer Priorisierung in das Product Backlog eingebaut. Dadurch wird dem Team eine Richtung vorgegeben und die wichtigsten Einträge stehen im Fokus. Alle Einträge sollten nach denselben festgelegten Kriterien priorisiert werden. Hierzu lassen sich die Faktoren Wert, Risiko, Auslieferbarkeit und Abhängigkeiten aufstellen. Ein wertvoller Eintrag ist einer, der zur Entstehung des Produkts wirklich notwendig ist. Bekannt ist, dass Produktentwicklungen mit Risiken einhergehen. Ein Risiko erfolgt aus Unsicherheit, Unsicherheit wiederum entsteht durch Wissensmangel. Somit kann ein risikoreicher Eintrag den Erfolg der Produktentwicklung beeinflussen. Aus diesem Grund sollten risikobehaftete Anforderungen mit der höchsten Priorität eingestuft werden. Unter der Auslieferbarkeit eines Produkts wird die Aktualisierung der Software verstanden. Die Software sollte frühzeitig und regelmäßig aktualisiert werden, sodass das Produkt mit der richtigen Funktionalität realisiert wird. Weiterhin gelten Abhängigkeiten als Kriterium für die Priorisierung der Einträge. Abhängigkeiten können zwischen verschiedenen Anforderungen entstehen, sie können aber auch angestoßen durch mehrere Teammitglieder im Scrum-Projekt zustande kommen. Falls Abhängigkeiten mit einer Anforderung einhergehen, so muss der Eintrag, der von anderen abhängt, zuerst implementiert werden und hat im Regelfall einen höheren Aufwand. Aus diesem Grund sollten Abhängigkeiten so weit wie möglich aufgelöst werden.

2.5 Sichtbar

Die letzte wichtige Eigenschaft eines Product Backlogs ist die der Sichtbarkeit. Das Product Backlog sollte für alle Scrum-Teammitglieder sichtbar und leicht zugänglich sein, da es als zentrales Kommunikationsmittel für die noch ausstehenden Arbeiten dient.

Produktmanager

3. Gestaltung des Inhalts eines Product Backlogs

Product Backlog Einträge werden, wie zuvor beschrieben, über den gesamten Projektverlauf hinweg identifiziert, verfasst, weiter detailliert und entfernt. Hierzu dient das Feedback der Kunden, Anwender und anderer Interessenvertreter. Bei der Erstellung des Product Backlogs werden die notwendigen Einträge zur Produktentwicklung vom gesamten Scrum-Team sowie von den Interessenvertretern gesammelt und eingetragen. Wichtig dabei ist, die Einträge zunächst nur zu skizzieren und die minimale Produktfunktionalität aufzuzeigen. Dabei ist es hilfreich, sich auf die Produktvision zu konzentrieren. Detaillierungen der am höchsten priorisierten Einträge können im nächsten Schritt erfolgen. Dadurch bleibt das Product Backlog übersichtlich und Veränderungen der Einträge sind leicht umzusetzen. Bevor eine Anforderung eingetragen wird, sollte stets das Kundenbedürfnis fokussiert werden. So werden nur die Anforderungen eingetragen, die auch zur Produktentwicklung beitragen.

User Stories

Das Verfassen der Anforderungen im Product Backlog kann auf unterschiedliche Art und Weise geschehen. Eine Art ist das Verfassen der Anforderungen mit User Stories. User Stories sind Geschichten, die verdeutlichen, wie das Produkt verwendet werden soll. Konkret umfasst eine User Story einen Namen, eine kurze Erzählung und Akzeptanzkriterien. Zur Erstellung einer Benutzergeschichte gelten 3-C-Kriterien: Card, Conversation und Confirmation. User Stories sollen kurz und knapp gehalten werden.

  • Card steht dafür, dass jede User Story auf einer Papierkarte abgebildet werden kann, denn so können die Anforderungen nicht bis ins kleinste Detail beschrieben werden.
  • User Stories stellen keine Kommunikationsmethode zwischen Projektmitgliedern oder zwischen Projektmitgliedern und Kunde dar. Sie sollen einzig die Bedeutung und Aussage der Anforderungen festhalten. Hierfür steht das zweite C – Conversation.
  • Zuletzt beinhaltet Confirmation, dass jede User Story messbar bzw. testbar ist. So kann der Product Owner die Umsetzung der Einträge überprüfen.

Zur Strukturierung der Einträge im Product Backlog werden diese ebenso nach Themen gruppiert. Anschließend werden zunächst die Themenblöcke nach Priorität strukturiert und im nächsten Schritt wird die Struktur der Einträge innerhalb eines Themas nach der Priorität angepasst.

Da das Product Backlog bei häufiger Bearbeitung und Anpassung schnell unübersichtlich wird, ist eine regelmäßige Pflege des Dokuments notwendig. Der Product Owner ist dafür verantwortlich, dass die Eigenschaften des Product Backlogs erfüllt werden, das gesamte Team setzt jedoch die Pflegemaßnahmen um. Zu den Pflegemaßnahmen zählen die Aufbereitung, Anpassung und Entfernung bestehender Einträge und das Hinzufügen neuer Anforderungen, die Priorisierung der Einträge sowie die Schätzung der bestehenden und der neuen Backlog-Einträge.

Agiles Projektmanagement und agiles Marketing im Seminar

Möchten Sie weiteren Input zum agilen Projektmanagement? Wir haben Seminare für Sie als Offene Formate, oder auch als Inhouse Workshops!

Sie möchten agile Methoden in Ihre Marketingprozesse implementieren? Dann besuchen Sie unser Seminar Agiles Marketing. Informieren Sie sich hier über die Inhalte oder sichern Sie sich jetzt einen Platz für das Seminar:

4. Product Backlog: Fazit

Im Product Backlog werden die ausstehenden Arbeitsschritte, die zur Produktentwicklung notwendig sind, durch den Product Owner festgehalten. Dazu werden Kundenbedürfnisse untersucht, Aufgaben der Markteinführung festgehalten und Fehler identifiziert, um diese schnellstmöglich zu beheben. Das Dokument sollte angemessen detailliert formuliert und fortlaufend angepasst werden. Die Einträge werden vorher abgeschätzt, nach Themen gruppiert und nach Priorität sortiert. Abschließend ist es wichtig, dass alle Team-Mitglieder Zugriff auf das Dokument besitzen, um über alle noch anstehenden Arbeitsschritte informiert zu sein.

Mehr finden Sie in unserem Erklärvideo!

Sie möchten Ihr Produktmanagement agil organisieren? Wir beraten Sie gerne!

Bastian FoersterHerr Bastian Foerster

Tel.: +49 (0)221 - 99 555 10 16
Fax: +49 (0)221 - 99 555 10 77
E-Mail senden

#ProductBacklog #Scrum #DIMProductBacklog #ProductOwner #Produktmanagement #AgilesProjektmanagement

Is Agile Dead? Diskussion zu agilen Methoden & Organisationsprinzipien

Is Agile Dead? Diskussion zu agilen Methoden & Organisationsprinzipien
5, 3 Bewertungen

In immer mehr Unternehmen häufen sich zunehmend misslungene agile Projekte (SCRUM). Denn ein Tool macht scheinbar noch keinen Sommer! Der Einsatz von SCRUM ist nicht in jedem Kontext sinnvoll und eine zweitägige Schulung mit einem Multiple Choice Test macht noch keinen erfahrenen SCRUM Projektmanager!

Also: Wie geht es richtig? Welche Tools machen Sinn? Und auf welche Rahmenbedingungen müssen wir beim erfolgreichen Einsatz achten?

Meetup: Reinventing Organizations

Am kommenden Montag, den 03.12.2018 ab 19:00 Uhr, führen wir gemeinsam mit Holger Gelhausen unser Meetup: Reinventing Organizations durch.

First come, first serve!

Digitales Board Nureva

Die Agenda:

  1. Welche agilen Methoden bzw. Methoden neuen Arbeitens gibt es?
  2. Wie sehen agile Organisationsprinzipien aus?
  3. Welche Organisationsprinzipien werden bei welchen Methoden angewandt?

Zum Einsatz kommt das innovative digitale Board von Nureva: https://www.nureva.com/visual-collaboration

Melden Sie sich schnell an: Wir haben nur noch wenige Plätze für den kommenden Montag frei!

Wann?
Montag, 03.12.2018, ab 19 Uhr

Wo?
DIM Deutsches Institut für Marketing GmbH
Hohenstaufenring 43-45
D-50674 Köln