Die DEEP-Kriterien Die Qualität des Product Backlogs einschätzen

Die DEEP-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob ein­zel­ne Pro­duct Back­logs “gut” sind. Das Akro­nym DEEP steht für fol­gen­de vier Eigen­schaf­ten: Beim → PMI steht zu DEEP /PMG-BA17/:“Descri­bes the cha­rac­te­ristics that a pro­duct → back­log needs to demons­tra­te to be con­side­red well refi­ned. DEEP is an acro­nym that stands for detail­ed appro­pria­te­ly, esti­ma­ted, emer­gent, and prio­ri­ti­zed.“Eige­ne …

Wei­ter­le­sen …

Agiles Schätzen Schnell und passend Schätzungen vornehmen

Unter “Agi­les → Schät­zen” (engl. Agi­le Esti­ma­ti­on) wird eine Rei­he von → Schätz­me­tho­den ver­stan­den, die ihren Ursprung in der agi­len → Soft­ware­ent­wick­lung haben, inzwi­schen aber auch in ande­ren Kon­tex­ten ein­ge­setzt wer­den. Beim Agi­len Schät­zen wer­den Anfor­de­run­gen, die typi­scher­wei­se in Form von → User Sto­ries erfasst wur­den, abge­schätzt.In die­sem Bei­trag wird das “Agi­le Schät­zen” beschrie­ben. Agiles … 

Wei­ter­le­sen …

Die INVEST-Kriterien User Stories gut und passend erfassen

Die INVEST-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob ein­zel­ne → User Sto­ries “gut genug” sind. Ursprüng­lich von Bill Wake im 2003 /INVEST-03/ vor­ge­stellt, kom­men die INVEST-Kri­­te­ri­en in fast allen Ent­wick­lungs­pro­jek­ten zum Ein­satz, in denen User Sto­ries ver­wen­det wer­den. Das Akro­nym INVEST steht für fol­gen­de sechs Eigen­schaf­ten: Abbil­dung 1 stellt die sechs Eigen­schaf­ten zusam­men­fas­send dar. Abbil­dung 1: Die … 

Wei­ter­le­sen …

Agiles Requirements Engineering Die Anforderungen im agilen Kontext passend erfassen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Agi­le → Requi­re­ments Engi­nee­ring (Abkür­zung: ARE) fasst alle Akti­vi­tä­ten zusam­men, die bei der Erfas­sung und Behand­lung von Anfor­de­run­gen in agi­len Kon­tex­ten / bei agi­lem Vor­ge­hen zum Ein­satz kom­men kön­nen.In die­sem Bei­trag wird das Agi­le Requi­re­ments Engi­nee­ring beschrie­ben. Agi­les Requi­re­ments Engi­nee­ring (ARE) ergänzt die agi­len Metho­den und Ansät­ze, wie sie bei­spiels­wei­se in → … 

Wei­ter­le­sen …

Der Product Owner Aufgaben, Verantwortlichkeiten und Rollenbeschreibung

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Der Pro­duct Owner ist eine zen­tra­le Per­son / Rol­le bei der Erfas­sung und Umset­zung von Anfor­de­run­gen in agi­len Pro­jek­ten und im → Agi­len Requi­re­ments Engi­nee­ring (ARE).In die­sem Bei­trag wird die Rol­le des Pro­duct Owners mit den Auf­ga­ben kurz beschrie­ben. Der Pro­duct Owner erfasst und ver­wal­tet die Anfor­de­run­gen bei agi­ler Vor­ge­hens­wei­se. Da bei … 

Wei­ter­le­sen …

Use Case oder User Story? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Begrif­fe → Use Case und → User Sto­ry wer­den häu­fig ver­wech­selt. Im → Requi­re­ments Engi­nee­ring ist eine Unter­schei­dung aber wich­tig.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zur Unter­schei­dung der Begrif­fe gelie­fert. → Use Cases und → User Sto­ries wer­den im Requi­re­ments Engi­nee­ring ein­ge­setzt und Anfor­de­run­gen zu erfas­sen. Hin­ter bei­den Schlag­wör­tern ver­ber­gen sich … 

Wei­ter­le­sen …

Personas Anforderungen aus typischen Nutzerprofilen ableiten

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Per­so­nas beschrei­ben Nut­zer (poten­zi­el­ler Pro­duk­te) und kön­nen bei der Ent­wick­lung von Anfor­de­run­gen ein­ge­setzt wer­den.Es wird in die­sem Bei­trag Per­so­nas beschrie­ben. Per­so­nas sind ein eta­blier­tes Kon­zept im → Agi­len Requi­re­ments Engi­nee­ring und hel­fen Anfor­de­run­gen auf Basis “fik­ti­ver Nut­zer” zu erstel­len. Sie unter­stüt­zen damit die Erstel­lung von → Use Cases (im klas­si­schen Fall) und … 

Wei­ter­le­sen …

Das Backlog Anforderungen und Einträge zentral verwalten

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Das Back­log ist eine Samm­lung von The­men, die bear­bei­tet wer­den sol­len. Meis­tens sind dies Anfor­de­run­gen, die im agi­len Kon­text in Form von → User Sto­ries notiert wer­den.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zum Back­log gelie­fert. Erläu­te­run­gen zum Back­log sind häu­fig in den Beschrei­bun­gen von → Scrum oder den → User Sto­ries enthalten. … 

Wei­ter­le­sen …

Definition of Done Wann ist eine User Story fertig umgesetzt?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Defi­ni­ti­on of Done (DoD) beschreibt, wann eine → User Sto­ry als fer­tig umge­setzt gilt, das heißt, vom Kun­den oder Anwen­der abge­nom­men wer­den kann.In die­sem Bei­trag wird eine Kurz­dar­stel­lung dazu gelie­fert. Erläu­te­run­gen zur Defi­ni­ti­on of Done sind häu­fig in den Beschrei­bun­gen von → Scrum oder den → User Sto­ries ent­hal­ten. Wenn → … 

Wei­ter­le­sen …