- 4 plans verplaatst naar docs/old/plans/ (M10-qr-pairing-login, auto-pr-deploy-sync, docs-restructure-ai-lookup, v1-readiness) - 3 archive-plans verplaatst naar docs/old/plans/ (archive-map nu leeg) - ST-1114-copilot-reviews + 3 research-docs naar nieuwe docs/Ideas/ map - Duplicaat docs/old/2026-04-27-m8-realtime-solo.md verwijderd (origineel zit in docs/old/plans/) - Link-fixes naar nieuwe locaties: - CHANGELOG.md → docs/old/plans/v1-readiness.md - docs/runbooks/deploy-control.md → docs/old/plans/auto-pr-deploy-sync.md (2x) - docs/runbooks/worker-idempotency.md → docs/old/plans/auto-pr-deploy-sync.md - docs/plans/docs-restructure-pbi-spec.md → docs/old/plans/docs-restructure-ai-lookup.md (4x text + 2x href) - docs/INDEX.md geregenereerd (96 docs, was 100) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7.6 KiB
| title | status | audience | language | last_updated | ||
|---|---|---|---|---|---|---|
| Advies — Product Backlog en Sprint-pagina workflow | draft |
|
nl | 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
- Product Backlog zonder actieve sprint: klassieke refinement-view zonder vinkjes.
- Product Backlog met nieuwe sprintdraft: metadata invullen, PBI's/stories selecteren via vinkjes, sprint aanmaken.
- Product Backlog met actieve sprint: product-breed zien welke PBI's/stories in de sprint zitten en membership in batches aanpassen.
- 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 Backlognaar iets alsAanvullen uit backlog; standaard filter op eligible stories:OPEN, nietDONE, geen andereOPENsprint. - 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_idblijft unit-of-truth. - Geen nieuwe afrondactie. De bestaande
completeSprintActionblijft 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 vanwhat.
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
- Hergebruik
commitSprintMembershipActionop de Sprint-pagina voor add/remove. - Vervang directe
addStoryToSprintAction/removeStoryFromSprintActioninSprintBoardClientgeleidelijk door een pending scope-buffer, of laat ze intern dezelfde transactiesemantiek gebruiken als tijdelijke tussenstap. - Fix bij die refactor ook task-cascade consistentie: remove moet
task.sprint_id = nullzetten voor taken onder verwijderde stories. - Gebruik de nieuwe
cross-sprint-blocksensprint-membership-summaryendpoints ook op de Sprint-pagina, maar gescoped op zichtbare PBI's. - Voeg later capacity toe als aparte story, niet als voorwaarde voor de eerste workflow-migratie.