Vanaf vandaag besteed je in alle user stories voor nieuwe website-functionaliteiten aandacht aan de inrichting van het CMS. Negeren kan niet meer!
CMS-frustraties
Webredacteuren klagen regelmatig over het niet functioneren van het Content Management Systeem (CMS) van een website. Het systeem is te langzaam, te beperkend, te gebruiksonvriendelijk, en ga zo nog maar even door. Met een ander systeem zou alles beter zijn. Ik geloof daar niet zo in: ik ben ervan overtuigd dat je met vrijwel ieder CMS prima uit de voeten kunt. Het probleem zit ‘m in de praktische inrichting. Een kleine greep uit de CMS-frustraties van een webredacteur/contentspecialist:
- Minutenlang zoeken naar het veld in het CMS waar je dat ene stukje tekst op een pagina moet aanpassen, met dank aan onlogische veldnamen en verstopte modules
- Collega’s die gebruik maken van de mogelijkheid om eindeloos lange teksten in titelvelden te proppen
- Tekst die hardcoded op de pagina staat en je dus niet zelf aan kan passen
Verantwoordelijkheid voor het CMS
Dat developers en contentspecialisten elkaars taal soms niet spreken, wordt pijnlijk duidelijk bij de oplevering van nieuwe functionaliteit voor een website. Ja, de nieuwe module functioneert, maar de gebruiksvriendelijkheid van het CMS laat te wensen over. Die vervelende developers weer, die snappen er ook niks van! Ze kunnen toch zelf ook wel bedenken dat dit niet werkbaar is? Of ligt er ook een stukje verantwoordelijkheid bij de contentspecialist?
Het antwoord op die vraag is natuurlijk: ja. Bij het agile ontwikkelen van nieuwe functionaliteit voor een website gebruiken we vaak user stories om duidelijk te maken wat we willen bereiken, zonder te beschrijven hoe we dat bereiken. Het is aan het team om dat te beantwoorden. En in dat team zit natuurlijk (ja toch?) ook de contentspecialist. Zodra de user stories uitgewerkt worden in concrete taken, kan je dus prima een zegje doen voor de inrichting van het CMS.
User stories en acceptatiecriteria
Een user story is eigenlijk een korte beschrijving van een gewenste situatie volgens een vast format. Dat ziet er zo uit:
als een <type gebruiker>
wil ik <iets doen>
zodat ik <er iets aan heb>
Op basis van deze beschrijving gaat het team in gesprek met de product owner. Wat is de gewenste werking van de user story? Tijdens de voorbereidende sessie (refinement) om de sprintwerkzaamheden helder te krijgen, worden alle details voor de user story vastgelegd in acceptatiecriteria. Dat betekent overigens niet dat het team dan zichzelf twee weken opsluit en aan het eind van de sprint functionaliteit oplevert. Tijdens de sprint blijven het team en de product owner continu in gesprek over de details van de user story.
CMS-inrichting als acceptatiecriteria opnemen
Alles dat niet gedefinieerd is in de acceptatiecriteria van de user story, wordt niet opgepakt in de sprint. En dat is waar het mis gaat: mensen doen aannames. “Ja, maar als ik een formulier wil, mag ik er toch wel van uitgaan dat ik daar verplichte velden in kan zetten?” Niet dus. Wat voor een contentspecialist heel logisch is, is niet per se logisch voor een developer. Aannames zijn dus gevaarlijk, dus daarom moet je uitspreken wat je precies wilt. Want in de acceptatiecriteria kun je dus prima criteria voor het CMS opnemen. Bijvoorbeeld dat de volgorde van de velden in het CMS hetzelfde moet zijn als wat je op de live omgeving ziet, dat er een karakterlimiet op een titelveld moet zijn, of dat invoervelden voor langere stukken tekst groot genoeg moeten zijn om de hele tekst te kunnen zien in het CMS. Of dat alle tekst in het CMS aan te passen moet zijn. Of dat de veldnamen logisch moeten zijn voor webredacteuren (dus geen technische termen). Nou ja, je snapt het idee: alle dingen die je wel en niet wilt, die moet je benoemen.
Goedkeuren CMS door de Product Owner
Ook slim om te doen: neem de acceptatie van de CMS-inrichting mee in je definition of done. Het verschil tussen de acceptatiecriteria en de definition of done is (heel grofweg) dat de acceptatiecriteria voor één user story gelden en de definition of done is overkoepelend. Pas als de product owner akkoord is met de inrichting, kan de story worden afgesloten.
Dus, vanaf vandaag gewoon die CMS-inrichting meenemen in je user stories hè?
