Featureverzoeken prioriteren die zich opstapelen

Featureverzoeken bijhouden lost op waar ze leven. Het lost niet op welk verzoek eerst gaat, en die tweede vraag is waar teams echt op vastlopen. Een backlog van driehonderd gegroepeerde, gelabelde verzoeken heeft nog steeds een beslisregel nodig, omdat “bouw het meest gevraagde ding” alleen werkt totdat twee verzoeken dicht bij elkaar liggen en een derde een luidruchtige voorstander heeft, wat de meeste weken het geval is. De frameworks hieronder zijn geen concurrerende antwoorden op dezelfde vraag. Elk past bij een ander type verzoek, en er één voor alle gebruiken is meestal de eigenlijke fout.

Wat maakt featureverzoeken prioriteren anders dan een roadmap prioriteren?

Een roadmapbeslissing start bij de strategie en vraagt wat te bouwen. Een beslissing over een featureverzoek start bij vraag die al bestaat en vraagt of er actie op moet komen, en die twee trekken vaak genoeg in verschillende richtingen dat een verzoek veel vraag kan hebben en toch verkeerd is om te bouwen, of weinig vraag kan hebben en toch de moeite waard is omdat het een strategisch account ontgrendelt. Elk verzoek behandelen als een roadmapstem slaat die controle over.

Wat is RICE, en werkt het voor featureverzoeken?

RICE scoort een idee op bereik, impact, vertrouwen en moeite, en deelt dan de eerste drie door de vierde voor een vergelijkbaar getal. Het is gebouwd voor roadmap-ideeën waar een team al in gelooft, waar het lastige deel is om ongelijke weddenschappen met elkaar te vergelijken. Featureverzoeken komen al met een bereikcijfer, de telling van mensen die vroegen, wat concreter is dan het bereik dat een vers roadmap-idee gewoonlijk heeft. Waar RICE onder spanning komt bij een verzoek is vertrouwen en impact: een team kan er zeker van zijn dat een verzoek echt is en toch geen basis hebben voor hoe sterk het een metriek zal bewegen, omdat “impact” voor een verzoek dat al een naam en een spoor van echte gebruikers heeft een ander soort schatting is dan impact voor een idee dat nog niemand buiten de kamer heeft gezien.

Gebruik RICE voor verzoeken die serieus worden overwogen en nog niet beslist zijn. Pas het niet toe op elk binnenkomend verzoek; de moeite van het scoren betaalt zich alleen uit bij verzoeken die dicht genoeg bij elkaar liggen om een tiebreaker nodig te hebben.

Moet je wegen naar omzet, of naar wie vroeg?

Naar wie vroeg, maar niet alleen naar omzet. Een account vlak voor verlenging, een account dat al eerder escaleerde, en een account waarvan het verzoek een lopende deal ontgrendelt, dragen een urgentie die een plat omzetcijfer alleen niet vastlegt, en een verzoek van een trialaccount kan nog steeds ertoe doen als het een beslissing blokkeert die binnenkort omzet wordt. Omzetweging is van deze het makkelijkst te berekenen, en juist daarom het makkelijkst om te veel op te vertrouwen: het haalt terecht ruis weg van accounts zonder echt belang, en het kan even makkelijk een verzoek degraderen dat een veel groter account zou binnenhalen dat nog in de pipeline zit.

Welke rol spelen stemmen eigenlijk?

Een goedkoop, doorlopend signaal voor verzoeken die al bestaan, en een slechte manier om te ontdekken welke verzoeken er überhaupt zouden moeten bestaan. Een stemmentelling bereikt alleen de gebruikers die het verzoek al vonden en het een klik waard vonden, wat betekent dat het totaal aan stemmen op een publieke roadmap net zoveel zichtbaarheid als vraag weerspiegelt: een oud verzoek hoog op de lijst blijft stemmen verzamelen deels omdat het makkelijk te vinden is, en een nieuwer, even echt verzoek begint bij nul. Het artikel over de publieke roadmap pleit ervoor stemmen helemaal van de roadmap te houden. Behandel stemmen als een signaal dat gegroepeerd en gewogen naar recentheid moet worden, niet als een ranglijst die je in volgorde afwerkt. Supporttickets vs. featureverzoeken behandelt de andere blinde vlek in stemmenaantallen: een echt gat kan bijna geen stemmen opleveren als de gebruikers die het raken het bord nooit vinden, terwijl het luidruchtig verschijnt in support.

Wanneer wint de luidruchtigste klant, en is dat een probleem?

Soms, en het is alleen een probleem als niemand het opmerkt. Een klant die vaak escaleert, gedetailleerde tickets schrijft of een directe lijn heeft met iemand in het team, ziet zijn verzoeken sneller behandeld dan een stillere klant met een even geldig verzoek, en een prioriteringsproces dat dit nooit controleert zal systematisch degene bevoordelen die het meest aandringt, niet degene met de sterkste zaak. Luidruchtige klanten zijn niet het probleem dat opgelost moet worden; hun verzoeken zijn vaak echt belangrijk. De oplossing is een gewoonte: periodiek de backlog per bron doorlopen en controleren of dezelfde handvol accounts het meeste verklaart van wat recent is uitgebracht, en je afvragen of dat overeenkomt met waar de echte vraag zit.

Hoe wordt een prioriteringsbeslissing een reactie?

Elke beslissing hier produceert winnaars en verliezers, en beide verdienen een reactie die de werkelijke redenering noemt, niet alleen een statuswijziging zonder uitleg. Hoe je een featureverzoek afwijst behandelt wat je zegt tegen een verzoek dat verloor, op een manier die de relatie intact houdt in plaats van als een generieke afwijzing te klinken. Het groeperings- en labelwerk dat dit alles mogelijk maakt wordt behandeld in featureverzoeken bijhouden; prioriteren werkt alleen op verzoeken die al zijn geregistreerd en goed genoeg gegroepeerd om te vergelijken.

FAQ

Wat is het beste framework om featureverzoeken te prioriteren? Geen enkele alleen. Gebruik ruwe tellingen om het luidruchtigste signaal te vinden, RICE om een korte lijst serieuze kandidaten te vergelijken, en een omzet- of accountcheck om gevallen te vangen waarin stille vraag van een strategisch account zwaarder weegt dan een luidruchtigere maar minder belangrijke groep.

Moeten featureverzoeken op dezelfde manier geprioriteerd worden als roadmap-ideeën? Nee. Roadmap-ideeën starten bij strategie; featureverzoeken starten bij vraag die al bestaat. Ze samen scoren zorgt ervoor dat een goed onderbouwde strategische weddenschap met weinig bestaande vraag consequent verliest van een verzoek dat gewoon meer mensen heeft die het vroegen.

Weerspiegelen stemmen op een publieke roadmap de vraag accuraat? Alleen onder mensen die het verzoek al vonden. Oudere, zichtbaardere verzoeken verzamelen sneller stemmen, ongeacht hoeveel echte vraag er achter een nieuwer verzoek zit, dus behandel stemtotalen als een signaal, gegroepeerd en gewogen naar recentheid, niet als een ranglijst die je in volgorde afwerkt.

Hoe vaak moeten prioriteiten van featureverzoeken opnieuw beoordeeld worden? Op een vaste cyclus, niet alleen wanneer iemand escaleert. Een maandelijkse of driemaandelijkse ronde die verzoeken hergroepeert en de weging herbekijkt, vangt afwijking op, zoals een handvol accounts dat domineert wat er wordt uitgebracht, wat een puur reactief proces nooit zelf naar boven brengt.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken