Prioriteiten

Om zaken gedaan te krijgen, moet je beslissen wat je gaat doen, en in welke volgorde je ze gaat doen.

In veel bedrijven worden prioriteiten (bijvoorbeeld over nieuwe features, bugs, refactorings, …) aangegeven volgens een schaal. Zo kan iets “High”, “Medium” of “Low” zijn. Wanneer een bedrijf dit systeem gebruikt, wordt na een tijdje een nieuwe categorie gecreëerd: “Highest”.

Hoe komt dat?

Stel je voor dat jij iets gedaan wil krijgen van je development-team. Men komt je vragen wat er belangrijk is en wat niet. Plichtsgetrouw markeer je een aantal features als “High”, en een aantal als “Low”. Vervolgens merk je dat de features die je als “High” aanmerkte, gedaan worden, maar degene die je als “Low” categoriseert worden nooit gedaan. Wat doe je volgende keer? Je duidt alles aan als “High”, natuurlijk.

Hier is het probleem

Als alles dringend is, is niets meer dringend. Na een tijdje werkt de strategie niet meer, en willen mensen toch kunnen aanduiden dat iets dringender is dan de rest. Op dat moment wordt “Highest” gecreëerd.

Als je wil weten wat je eerst moet doen, plaats dan zaken in een volgorde (in overleg met je stakeholders). Geef ze geen prioriteiten. “Eerst doen we feature A, dan doen we bug fix B, en daarna doen we refactoring C. Iedereen akkoord?”