Het requirementswerk dat refinement heet

Dezelfde vragen, in een ander ritme

Refinement is het doornemen en bijschaven van backlogitems voordat ze aan de beurt zijn. De requirementscursus legt naast die sessie de vragen die in de delen ervoor zijn geoefend: is dit item voor meer dan één uitleg vatbaar, wie heeft hier mandaat over, raakt het een ander systeem, en draagt het aantoonbaar bij aan een hoger doel. Dat zijn de vragen van elicitatie en validatie, gesteld over één item en in het tempo van een sprint.

Uit die opsomming trekt datzelfde materiaal een conclusie die verder gaat dan een beschrijving van de ceremonie. Refinement staat er niet als een activiteit naast requirements engineering; het is requirements engineering, in een lichter en frequenter ritme uitgevoerd. De zin erachter maakt er een oordeel van:

Wie refinement ziet als "iets anders dan RE", mist de kern van dit deel.

Dat oordeel gaat over hoe het vak wordt gelezen, en daarmee is het ook bruikbaar in een team dat de rol van analist niet kent: het werk is er dan nog steeds, alleen zonder naam.

Wat er niet lichter wordt

Het materiaal zet daar meteen drie dingen naast die hetzelfde blijven wegen: kwaliteit, traceerbaarheid en de rolgrens. Wat verandert is het ritme waarin ze worden toegepast, lichter en vaker. Een user story blijft onderworpen aan dezelfde kwaliteitscriteria als een requirement, en de beheerattributen, waar een eis vandaan komt en wie erover gaat, verhuizen mee naar het backlogitem zelf.

Waar die nadruk vandaan komt, staat in het eerste deel van dezelfde cursus. De vaakst gehoorde misvatting is daar dat agile werken requirements overbodig maakt. Wat er volgens dat deel overbodig wordt, is het tegelijk vooraf compleet vastleggen ervan, en dat is een andere claim. Refinement is in die lezing de plek waar dat vastleggen alsnog gebeurt, item voor item.

Waar het werk uit beeld raakt

Werk dat in een sessie gebeurt, laat minder sporen na dan werk dat in een document staat. De cursus benoemt op drie plaatsen wat er dan misgaat, telkens met een valkuil erbij die uit het snelle ritme zelf voortkomt.

De eerste gaat over de wijziging die klein lijkt. Bij elk nieuw of gewijzigd item horen vier vragen: waar komt dit vandaan, wat raakt het, verschuift de prioriteit van iets anders, en wie beslist. In een formeel proces staan die op een wijzigingsformulier; in refinement duren ze minuten. Het lesmateriaal stelt dat de verleiding om ze over te slaan juist in een snelle omgeving groter is, omdat het maar een kleine wijziging is. Onderzocht is die uitspraak niet; ze staat er als waarneming bij een casus.

De tweede gaat over wat er tussen de items door valt. Beslisregels en kwaliteitseisen die dwars door meerdere backlogitems heen lopen, horen bij geen enkel item in het bijzonder. Het materiaal beschrijft wat er dan gebeurt: ze verdwijnen ertussen, en het team vindt de regel in elk item opnieuw uit, met onderlinge tegenspraak als gevolg. De remedie die er staat is licht. Een apart bijgehouden tabel met beslisregels naast de backlog is volgens dat deel het verschil tussen een team dat de regel kent en een team dat hem elke keer opnieuw bedenkt.

De derde gaat over de systeemgrens. Die mag per iteratie verschuiven, en bij werk met hoge onzekerheid is dat de bedoeling. De valkuil die het materiaal aanwijst is dat hij ongemerkt verschuift, waarna niemand meer kan reconstrueren wat er ooit was afgesproken. Het lichtste gereedschap dat daartegen werkt is volgens dat deel een korte, actuele lijst met wat er aan de grens nog openstaat.

Wat er aan tafel bij komt

Wat een analist aan zo'n sessie toevoegt, is in dit materiaal geen extra werkproduct maar een vaste set vragen bij elk item, en het vasthouden aan het antwoord.

Het begint bij herkomst. Een requirement zonder herkomst is volgens deel 1 een aanname, en bij elk item hoort dus de vraag wie dit vindt en waarom. Daarachter ligt de laag eronder. Wat iemand aandraagt is vaak al een oplossing, en het materiaal waarschuwt dat een acceptatiecriterium dat een schermelement beschrijft nog steeds een oplossing is die als eis is opgeschreven, alleen in een kortere zin. Doorvragen naar het doel erachter kost in een sessie een paar minuten en levert de ontwerpruimte op die de formulering anders had weggegeven.

Dan is er de vraag wie erover gaat. Het materiaal zegt dat je die toetst bij de belanghebbende zelf of bij de programmamanager, en het noemt de veelvoorkomende aanname erbij: dat wie het hardst spreekt ook het meeste mandaat heeft. Dat is regelmatig niet zo.

Uit die laatste vraag komt een concrete afspraak die de cursus zelf voorstelt. Een item dat wacht op een besluit van buiten het team krijgt die status met zoveel woorden in de backlog, en niet de status geblokkeerd, want die wekt de indruk dat het team er iets aan kan doen. Dat is een kleine ingreep met een zichtbaar gevolg: het formele traject kan alvast starten naast het sprintwerk, en niemand verwacht dat zo'n item in dezelfde tijd wordt afgerond als de rest.

Waar de rol ophoudt

De requirementscursus trekt de lijn in het eerste deel al. De requirements engineer levert feiten, opties en consequenties; het besluit ligt bij anderen. Wie die lijn laat vervagen, wordt volgens dat deel machteloos of gevaarlijk, en beide woorden staan er met uitleg: machteloos omdat het gaat lijken alsof hij maar wat verzint, gevaarlijk omdat anderen gaan denken dat hij het blijkbaar heeft besloten.

Dezelfde lijn staat in de SAFe-cursus, daar bij de rol die een overleg voorzit. Wie zelf de oplossing voor een probleem aandraagt, ontneemt de teams de kans dat zelf te doen en ondermijnt op termijn hun probleemoplossend vermogen. Dat is daar geschreven over een release train engineer in een coördinatieoverleg, en aan een refinementtafel geldt het voor iedereen die het antwoord al klaar heeft.

De testcursus komt van de derde kant. Shift-left is daar een organisatorische keuze: het vereist dat de tester al bij refinement wordt uitgenodigd, en die uitnodiging moet iemand anders geven. Bij de opdracht in dat deel staat waar het meedenken van die tester ophoudt. Hij bevraagt en maakt toetsbaar; over de inhoud van de eis beslissen de business analist en de product owner. Het risico dat daar wordt genoemd is dat de tester ongemerkt eisensteller wordt.

Drie cursussen leggen die lijn dus voor drie verschillende rollen op dezelfde plaats: informatie leveren zonder het besluit over te nemen. Ze doen dat wel elk voor zich. Geen van de drie verwijst naar de andere twee, en het naast elkaar leggen gebeurt hier.

Wat hier open blijft

Of dit werk een eigen persoon nodig heeft, staat nergens in dat materiaal.

De cursus beschrijft het werk en niet de bezetting. Een team dat de vier vragen zelf stelt, de herkomst per item zelf bijhoudt en de beslisregels zelf apart legt, voldoet aan wat er staat. Of dat gebeurt zonder iemand die het als zijn vak beschouwt, is een vraag naar gedrag onder tijdsdruk, en een lezing van lesmateriaal levert daar geen antwoord op.

Er staat één uitspraak in die richting die niet is nagerekend: dat een korte refinementsessie met twee gerichte waarom-vragen vaak meer oplevert dan een uur ongestructureerd doorvragen vooraf. Er staat geen meting onder, dus hij staat hier als bewering van het lesmateriaal. Om dezelfde reden voert dit artikel geen enkel cijfer op over wat refinement oplevert.

Het derde niveau van diezelfde cursus laat zien waar de vraag heen loopt zodra er meer dan één team is. Elk team heeft dan een eigen backlog, een eigen sprintlengte en een eigen refinementritme, elk intern consistent en niet vanzelf op elkaar afgestemd. De classificatie van dezelfde wijziging valt daardoor per team anders uit. Het materiaal benoemt dat en laat in het midden bij wie het bij elkaar houden dan hoort.

Wie het zonder een analist ziet werken, of juist niet, heeft daarmee het stuk in handen waarop dit artikel is aan te vallen, en dat gesprek hoort bij het onderwerp naast dit stuk.