--- title: "Advies — Product Backlog en Sprint-pagina workflow" status: draft audience: [product, ai-agent] language: nl last_updated: 2026-05-11 --- # Advies — Product Backlog en Sprint-pagina workflow ## Aanleiding Het bestaande plan `dit-verhaal-gaat-over-dazzling-mccarthy.md` beschrijft een nieuwe Product Backlog-workflow waarin sprint-membership via vinkjes wordt beheerd. De vraag is hoe de Sprint-pagina daarop moet aansluiten, met als doel om de huidige sprint verder samen te stellen. ## Korte conclusie Maak de Product Backlog-pagina de brede plek voor backlog-refinement en sprint-scope selectie, en maak de Sprint-pagina de werkomgeving voor de huidige sprint: scope bijstellen, volgorde bepalen, taken uitwerken, assignees zetten, capaciteit bewaken en afronden. De twee pagina's mogen dezelfde onderliggende membership-acties gebruiken, maar ze moeten niet dezelfde primaire UI dupliceren. De Product Backlog is de product-brede selectie- en overzichtslaag. De Sprint-pagina is de sprint-specifieke uitwerkingslaag. ## Verhouding tussen de pagina's | Pagina | Primaire vraag | Scope | Hoofdhandeling | |---|---|---|---| | Product Backlog `/products/[id]` | Wat is waardevol, wat is klaar, wat hoort bij welke sprint? | Alle PBI's/stories van het product | Refinen, ordenen, nieuwe sprintdraft maken, sprint-membership bulk selecteren | | Sprint-pagina `/products/[id]/sprint/[sprintId]` | Hoe maken we deze sprint uitvoerbaar en af? | Een gekozen sprint | Sprint Backlog ordenen, stories aanvullen/verwijderen, taken maken, eigenaarschap/capaciteit/voortgang beheren | ## Aanbevolen workflow 1. Product Backlog zonder actieve sprint: klassieke refinement-view zonder vinkjes. 2. Product Backlog met nieuwe sprintdraft: metadata invullen, PBI's/stories selecteren via vinkjes, sprint aanmaken. 3. Product Backlog met actieve sprint: product-breed zien welke PBI's/stories in de sprint zitten en membership in batches aanpassen. 4. Sprint-pagina: huidige sprint verder samenstellen en uitvoeren. Het middenpaneel is de waarheid voor de huidige Sprint Backlog. Het backlogpaneel is alleen toevoer/context. ## Consequenties voor de Sprint-pagina Aanbevolen aanpassing: - Header toont Sprint Goal, dates, status, switcher, scope-dirty teller en afronden-flow. - Linkerpaneel hernoemen van `Product Backlog` naar iets als `Aanvullen uit backlog`; standaard filter op eligible stories: `OPEN`, niet `DONE`, geen andere `OPEN` sprint. - Middenpaneel blijft `Sprint Backlog`: geselecteerde stories, sortering, assignee, task-progress, remove. - Rechterpaneel blijft `Taken`: taakdecompositie, taakvolgorde, status, implementatieplan. - Membership-mutaties op de Sprint-pagina gebruiken dezelfde serveractie als de Product Backlog: `commitSprintMembershipAction(activeSprintId, adds, removes)`. - Scopewijzigingen zijn pending/dirty tot `Scope opslaan (N)`. Story/task-field edits blijven direct opslaan. - Cross-sprint conflicts tonen als disabled story met tooltip. Server blijft autoritatief. - Na start van een sprint markeer je add/remove visueel als scopewijziging, omdat dat gevolgen heeft voor burndown/rapportage. Wat je juist niet moet doen: - Geen tweede volledige PBI-tri-state bulkselectie bouwen op de Sprint-pagina. Dat hoort op de Product Backlog. - Geen aparte sprint-membership semantiek naast het plan. `story.sprint_id` blijft unit-of-truth. - Geen nieuwe afrondactie. De bestaande `completeSprintAction` blijft de sprint-completion-flow. ## Andere methoden uit websearch ### 1. Scrum Guide: why / what / how De Scrum Guide beschrijft Sprint Planning als drie onderwerpen: waarom is deze sprint waardevol, wat kan deze sprint gedaan worden, en hoe wordt het gekozen werk gedaan. De Sprint Backlog bestaat uit Sprint Goal, geselecteerde PBIs en een uitvoerbaar plan. Impliceert voor Scrum4Me: - Product Backlog-pagina: vooral `what`. - Sprint-pagina: vooral `how`, plus gecontroleerde bijstelling van `what`. Bron: https://scrumguides.org/scrum-guide.html ### 2. Jira-methode: sprints plannen vanuit backlog, board voor active sprint Jira plant sprints op het Backlog-scherm. De backlog toont werk gegroepeerd in backlog en sprints; items kunnen naar sprints worden gesleept. Na start verschijnt de sprint op het board. Jira waarschuwt ook dat add/remove in een actieve sprint scope change is. Impliceert voor Scrum4Me: - De richting van het plan is marktconform: sprint-samenstelling vanuit de backlog. - De Sprint-pagina mag scope aanpassen, maar moet dat als scopewijziging behandelen. Bronnen: - https://support.atlassian.com/jira-software-cloud/docs/use-your-scrum-backlog/ - https://support.atlassian.com/jira-software-cloud/docs/enable-sprints/ - https://support.atlassian.com/jira-software-cloud/docs/plan-a-sprint/ ### 3. Azure Boards-methode: eerst items toewijzen, daarna capaciteit checken Azure Boards beschrijft sprintplanning in twee delen: eerst backlog items selecteren, daarna bepalen hoe het team ontwikkelt/test, taken definiëren en capaciteit controleren. Azure toont geplande effort en capaciteit om onder- of overbelasting zichtbaar te maken. Impliceert voor Scrum4Me: - Voeg op de Sprint-pagina een lichte capacity/forecast-strip toe zodra story points, effort of taakminuten beschikbaar zijn. - Laat de Sprint-pagina na selectie vooral helpen met taakdecompositie en load balancing. Bronnen: - https://learn.microsoft.com/en-us/azure/devops/boards/sprints/assign-work-sprint - https://learn.microsoft.com/en-us/azure/devops/boards/sprints/adjust-work ### 4. Backlog refinement als aparte continue praktijk Atlassian beschrijft refinement als doorlopend reviewen, rangschikken en verduidelijken van de Product Backlog zodat Sprint Planning soepeler loopt. Impliceert voor Scrum4Me: - Houd refinement-controls op de Product Backlog: PBI/story details, status, priority, split/merge later. - Maak de Sprint-pagina niet de primaire plek voor product-brede refinement. Bron: https://www.atlassian.com/agile/scrum/backlog-refinement ### 5. Linear cycles / Scrumban-achtige methode Linear cycles zijn time-boxed perioden met een vooraf bepaalde set werk, inclusief automatiseringen zoals rollover en auto-add van actieve issues. Dit is minder strikt Scrum, maar nuttig voor solo/kleine teams. Impliceert voor Scrum4Me: - Eventueel later: optionele automation "carry over unfinished stories to next sprint". - Niet als basis voor de huidige Scrum4Me-flow, omdat Scrum4Me al Sprint Goal, Sprint Backlog en completion-semantiek heeft. Bron: https://linear.app/docs/use-cycles ## Aanbevolen ontwerpkeuze Kies voor een hybride die dicht bij Scrum/Jira/Azure ligt: - Product Backlog = refinement + sprint-scope bulkselectie. - Sprint-pagina = huidige sprint afmaken: ordenen, decomponeren, capaciteit en uitvoering. - Eén gedeelde membership-laag in code: dezelfde conflictregels, task cascade, statusmutaties en affected-id returns. Dit houdt het mentale model simpel: je kunt overal zien wat in de sprint zit, maar elke pagina heeft een eigen reden om te bestaan. ## Implementatie-notities 1. Hergebruik `commitSprintMembershipAction` op de Sprint-pagina voor add/remove. 2. Vervang directe `addStoryToSprintAction` / `removeStoryFromSprintAction` in `SprintBoardClient` geleidelijk door een pending scope-buffer, of laat ze intern dezelfde transactiesemantiek gebruiken als tijdelijke tussenstap. 3. Fix bij die refactor ook task-cascade consistentie: remove moet `task.sprint_id = null` zetten voor taken onder verwijderde stories. 4. Gebruik de nieuwe `cross-sprint-blocks` en `sprint-membership-summary` endpoints ook op de Sprint-pagina, maar gescoped op zichtbare PBI's. 5. Voeg later capacity toe als aparte story, niet als voorwaarde voor de eerste workflow-migratie.