De backlog vullen

We starten met het vullen van de backlog door een aantal Epics, Features en PBI’s in te voeren. Als we dit doen wordt alles aangemaakt als Draft, dit betekent dat het wel zichtbaar is in onze project view, maar niet vanuit de GitHub Repos. Ik kies ervoor om alles naar een issue om te zetten. Als ik alles heb ingevuld, hebben we onderstaande backlog met issues.

Je ziet dat alle omschrijvingen als laatste het issuenummer toegevoegd krijgen, dit vul je niet zelf in maar dat wordt bij het omzetten van een draft issue naar een issue gedaan (wat alleen mogelijk is als je daadwerkelijk een repo hebt aangemaakt die aan dit project is gekoppeld).  Als ik het eerste issue bewerk dan zie je ook dat de omschrijving zonder toevoeging van het nummer is.

 

Wat ook opvalt is dat het heel lastig is te onderscheiden wat de Epics, Features of PBI’s zijn. Wat je kunt doen is een naamconventie af spreken, bijvoorbeeld EPIC – naam, FEATURE – naam et cetera, maar dat is lastig om consequent door te voeren (zeker niet wanneer er veel mensen zijn die bijdragen kunnen leveren).

Extra veld

Een andere oplossing om dit te verduidelijken is een extra veld aanmaken, genaamd type. Hier heb ik een lijst van gemaakt en daarin de drie beschikbare waardes meegegeven (altijd nog uit te breiden met Bugs, Tasks et cetera). Als eerste heb ik een icoontje erin gezet en daarna de omschrijving (en om dicht bij Azure DevOps te blijven, icoontjes die lijken op de in Azure DevOps gebruikte iconen).

Iconen kun je toevoegen door “:” gevolgd door omschrijving van de icon te typen. Bijvoorbeeld “:crown” , “:trophy” en “:book” en dit aan te vullen met de omschrijving. Na het toevoegen van de types heb ik elk issues het juiste type gegeven.

Kolommen verplaatsen

Persoonlijk zie ik graag als eerste welk type issue het is. Je kunt de volgorde van kolommen eenvoudig veranderen door deze te slepen. Als je op de titel van de kolom staat komt er een handje, met behulp van de rechtermuisknop selecteer je de kolom en kun je hem verplaatsen. De eerste kolom is het positie op de backlog en kun je niet veranderen, maar verder kun je hem op elke andere plek neerzetten.

Het eindresultaat:

Ordenen

Volgende stap is de issues ordenen, zodat er een hiërarchie ontstaat. Op deze manier kun je eenvoudig zien wat bij elkaar hoort. Je ordent door met je muis bij het issue nummer (eerste kolom) te staan, er verschijnt een handje en je kunt de regel verplaatsen naar de gewenste plek. Nu staan de work items gegroepeerd.

Issues linken

Er is nog geen hiërarchie in issues. We hebben nu zelf een hiërarchie gemaakt door het type mee te geven en de issues te ordenen. Nadeel is nu nog dat als je een issue opent je niet ziet waar deze nu bij hoort, en als we in de loop van de tijd issues gaan toevoegen, verplaatsen et cetera dan ben je al snel het overzicht kwijt. Om dit te voorkomen heb ik 2 extra velden gemaakt:

• Epic
• Feature

Dit zijn vrije tekst velden die je kunt vullen met alles wat je wilt, wat ik doe is er een hyperlink in zetten. Je kunt ook de naam invoeren, maar mocht deze wijzigen dan is een hyperlink naar het nummer een beter alternatief. In onze demo is het eerste Epic Payments. De Feature Shipping & Delivery hoort hierbij. Bij de  Feature Shipping & Delivery heb ik in het veld Epic de link naar de Epic Payments opgenomen. En bij de PBI’s die horen bij de Feature Shipping & Delivery heb ik in de kolom Feature de link naar het Feature opgenomen.

 

Dit alles vereist nog steeds handwerk, discipline en goed opletten. Totdat er een oplossing is voor hiërarchie in GitHub is dit een goed alternatief. Er is op dit moment een beperkte beta waarin deze functionaliteit uitgebreid getest wordt, maar er is nog geen datum wanneer dit uitgerold wordt naar alle gebruikers.

View maken

Je kunt nu ook een view maken waarbij je groepeert op bijvoorbeeld alle features en bijbehorende PBI’s. Selecteer bovenin “New view”

Hernoem de nieuwe view naar Features, selecteer de dropdown icon en kies filter (of gebruik de shortcut)

Selecteer type is PBI

Voeg vervolgens het veld Feature toe

Groepeer de view op Feature, kies Table view en sla de wijzigingen op.

 

In deze view heb je nu een overzicht van alle Features die 1 of meerdere PBI’s gelinkt hebben.

Op deze manier kun je ook een view maken per feature, bijvoorbeeld:

Dagelijkse wijzigingen en verbeteringen

In de toekomst kijken is lastig. GitHub heeft een pagina beschikbaar waar dagelijks alle GitHub updates en verbeteringen geplaatst worden. Door de hoge frequentie van wijzigingen kunnen bepaalde items in dit blog niet meer of anders werken. Mocht je hier tegenaan lopen dan hoor ik dat graag.

Publieke roadmap

GitHub publiceert online ook de GitHub roadmap voor de komende periode (op moment van schrijven tot en met Q3 2023 (en als laatste de kolom Future). Op deze pagina kun je de geplande en gerealiseerde items zien. Op dit moment kun je zien wat er in Q3 geshipped is en in Q4 gepland en deels al geshipped is daar waar het gaat om work item management.

Conclusie

Wanneer je deze stappen hebt doorlopen heb je:

• Visueel inzicht in wat voor type een issue is: Epic, Feature of PBI
• Issues aan elkaar gelinkt waar nodig: Feature aan Epic en PBI aan Feature
• Een view waarin je alle Features ziet waar 1 of meerdere PBI’s voor zijn
• Een view voor 1 feature, mocht je alleen willen focussen op een specifieke feature

Mocht je er toch niet uitkomen, vragen of feedback hebben dan hoor ik het graag.

Of schrijf je in voor ons webinar over workitem management in GitHub op vrijdag 3 maart.

Marcel Groennou, Business Unit Manager DevOps

In een volgend blog ga ik verder in op het gebruik van Kanban boards binnen GitHub.