Ein Autor ist berechtigt, neue Seiten im Wiki anzu­legen und beste­hende Seiten zu ändern oder zu löschen. Seine Auf­gabe ist es, Seiten im Wiki inkre­men­tell mit Pro­dukt­wissen zu füllen. Er nutzt dabei vorge­fertigte Bau­steine und folgt den Prinzi­pien und Prak­tiken von cards+. Der Autor ist ver­ant­wort­lich für die Quali­tät seiner Seiten. Er ist auch Modera­tor der Kommen­tare seiner Seiten.

Jede Seite im Wiki hat einen Autor. Im Regel­fall gilt die Per­son, die eine Seite zuletzt geän­dert hat, als aktu­eller Autor und damit verant­wort­lich für den Inhalt der Seite. Das ist ein prag­matischer Ansatz, der bei­spiels­weise von Confluence gut unter­stützt wird.

Der Pro­dukt­verant­wort­liche ist bei agiler Soft­ware-Ent­wick­lung natur­gemäß der wich­tigste Autor. Er trägt die Ver­ant­wortung für das Pro­dukt, inhalt­lich und wirt­schaft­lich. Die Pro­dukt­doku­men­tation und damit auch das Wiki ist ein Teil jedes Pro­dukt­inkre­men­tes.

In einem kom­plexen Pro­jekt­umfeld oder bei «jungen» Pro­jek­ten mit rasanten Ver­änderun­gen benötigt der Pro­dukt­verant­wort­liche sehr häufig Unter­stützung durch ein Spezial-Team aus Exper­ten ver­schiede­ner Diszi­pli­nen.

In kleinen oder «reifen» Pro­jekten über­nehmen Ver­treter des Teams die Auf­gaben des Spezial-Teams zur Unter­stützung des Pro­dukt­verant­wort­lichen.

Ein Analyst ist als Teil des Spezial-Teams zur Unter­stützung des Pro­dukt­verant­wort­lichen der Autor der Bau­steine der System­beschrei­bung. Mit den Bau­steinen Epic und Case sichert er seine Ergeb­nisse aus der Anfor­derungs­ana­lyse.

Ein UX-Experte ist als Teil des Spezial-Teams zur Unter­stützung des Pro­dukt­verant­wort­lichen der Autor für alle Varian­ten des Bau­steins Layout. Er ist unver­zicht­bar beim Ent­wurf einer Gestal­tungs­richt­linie (engl. style guide) und bei der Ent­wick­lung einer Bedien­ober­fläche mit opti­maler Nutzer­erfah­rung (engl. user experi­ence). Er klärt Fra­gen der Ergo­nomie und Bariere­frei­heit einer Anwen­dung.

Ein IT-Experte ist als Teil des Spezial-Teams zur Unter­stützung des Pro­dukt­verant­wort­lichen der Autor für den Bau­stein Decision. Damit hält er Rand­bedingun­gen, Quali­täts­anfor­derun­gen und andere entschei­dende Ein­flüsse auf die Soft­ware fest. Die System­struk­tur doku­men­tiert er in Abstim­mung mit den Ent­wick­lern mit den Bau­steinen Domain, Service, Entity und Event. Ganz wesent­lich ist, dass sie dort abge­stimmte über­greifende Kon­zepte der Imple­men­tierung fest­hal­ten.

Ein Ent­wick­ler schreibt in erster Linie Spezifi­katio­nen für Dienste und Objekte des IT-Systems. Diese Spezifi­katio­nen zählen zur Pro­dukt­doku­men­tation. Durch geeig­nete Werk­zeuge werden alle freige­gebenen Spezifi­katio­nen im Wiki zum Lesen ver­öffent­licht. Ein Entwickler unter­stützt den Produkt­verantwort­lichen, indem er mit dem Abschluss der Implemen­tierung seine Lösung im ent­sprechenden Baustein Case ergänzen. Jede dort beschriebene Lösung bezieht sich auf die Bausteine der Systems­truk­tur. Ent­wick­ler doku­men­tie­ren mit den Bau­steinen Domain, Service, Entity und Event den Fort­schritt der Reali­sierung von Diensten und Objekten. Ganz wesent­lich ist, dass sie dort Besonder­heiten und wich­tige Erkennt­nisse der Imple­men­tierung fest­hal­ten.

Ein Tester schreibt in erster Linie Test­fälle und organi­siert sie in Test­plänen in einer Test­pyra­mide. Die Test­pläne werden manuell oder auto­matisch ausge­führt. Durch geeig­nete Werk­zeuge werden alle freige­gebenen Test­pläne im Wiki zum Lesen ver­öffent­licht. Ein Tester unter­stützt den Pro­dukt­verant­wort­lichen, indem er sicher­stellt, dass für jeden Bau­stein Case, für den es eine Imple­men­tierung gibt, mindes­tens ein Test­fall vorhanden ist.