Du har skrivit en TRD. Du har samordnat på canvas. Du har skapat en plan med Nu/Nästa/Senare-prioriteringar. Nu kommer den svåra delen: faktiskt bygga det.
Detta är där de flesta planeringar faller isär. Du har en vacker plan som säger “Bygg autentiseringssystem” men ingen tydlig definition av vad “klart” ser ut som. Tre veckor senare är du 80% klar med allt och 100% klar med ingenting. Demon är pinsamma. Intressenter är förvirrade. Du drunknar i halvfärdiga funktioner.
Problemet är inte brist på arbete—det är brist på spårning. Du behöver ett system som bryter ner planer i handlingsbara uppgifter, definierar vad “klart” betyder, och håller alla ärliga om framsteg.
Här är hur man går från backlog till klart utan att förlora sitt förnuft.
Anatomin av ett bra backlog-objekt
Ett backlog-objekt är inte bara en att-göra. Det är ett kontrakt: “När X är sant är denna uppgift komplett.”
Här är vad som skiljer ett bra backlog-objekt från en vag önskan:
Dåligt backlog-objekt
- [ ] Implementera autentisering
Vad betyder “implementera”? Email/password? OAuth? Båda? Vad med lösenordsåterställning? Sessionshantering? Rollbaserad åtkomst? Du kommer spendera två veckor med att bygga och fortfarande inte vara “klar” eftersom ingen definierade det.
Bra backlog-objekt
## AUTH-001: Email/Password-registreringsflöde
**Status:** Att göra
**TRD Ref:** Sektion 4.1 (Användarautentisering)
**Prioritet:** Hög
**Arbete:** 3 dagar
**Ägare:** @alex
**Beroenden:** Inga
### Beskrivning
Implementera email/password-registrering med validering, bcrypt-hashing och JWT-token-generering.
### Acceptanskriterier
- [ ] Användare kan POST /api/signup med email + lösenord
- [ ] Emailvalidering: RFC 5322-format, avvisa ogiltiga adresser
- [ ] Lösenordskrav: min 12 tecken, 1 versal, 1 siffra, 1 symbol
- [ ] Lösenord hashade med bcrypt (kostnadsfaktor 12)
- [ ] Lyckad registrering returnerar JWT (24h utgång) + refresh token (30 dagar)
- [ ] Dubbel email returnerar 409 Conflict med tydligt felmeddelande
- [ ] Rate limiting: max 5 registreringsförsök per IP per timme
- [ ] Enhetstester täcker alla valideringsregler
- [ ] Integrationstest täcker fullt registreringsflöde
### Utanför scope
- Lösenordsåterställning (AUTH-003)
- Emailverifiering (AUTH-004)
- OAuth-inloggning (AUTH-005)
Nu är “klart” otvetydigt. Du kan inte påstå att denna uppgift är komplett förrän alla nio acceptanskriterier är checkade. Ingen 80%-klar-tvetydighet.
De fem väsentliga fälten
Varje backlog-objekt behöver dessa fält:
1. Unikt ID (t.ex. AUTH-001)
Använd ett prefix + nummer: AUTH-001, FEAT-042, BUG-015. Detta gör objekt spårbara i commits, PR:er och Slack.
Varför: När någon frågar “Fixade vi session timeout-buggen?” söker du BUG-023 istället för att scrolla genom 100 uppgifter.
Format: [KATEGORI]-[NUMMER] där kategori är AUTH, FEAT, BUG, PERF, DOCS, etc.
2. TRD-referens (vilket krav tillfredsställer detta?)
Länka tillbaka till TRD-sektionen som motiverar detta arbete.
Varför: Förhindrar föräldralösa funktioner. Om det inte finns någon TRD-referens, fråga: “Bygger vi något ingen begärt?”
Exempel: TRD Ref: Sektion 4.1 (Användarautentisering)
3. Prioritet (Hög/Medel/Låg)
Inte allt är brådskande. Var ärlig om vad som flyttar nålen.
Hög: Blockerar annat arbete, kritiskt för lansering, hög användarströmmar Medel: Viktigt men inte blockerande, kan skeppa utan det initialt Låg: Nice-to-have, polish, framtida förbättringar
4. Arbete (Tidsuppskattning)
Uppskatta i dagar eller story points. Var realistisk, inte aspirationell.
Varför: Hjälper med planering. Om du har 2 veckor och 6 hög-prioritets-objekt som totalt är 15 dagars arbete måste något flytta till Nästa.
Tips: Lägg till 50% buffert för okända faktorer. En “2-dagars uppgift” är förmodligen 3 dagar.
5. Acceptanskriterier (testbara checkboxar)
Det viktigaste fältet. Detta är vad “klart” ser ut som.
Regler:
- Måste vara specifika och testbara
- Måste vara binära (ja/nej, inte “mestadels fungerar”)
- Bör inkludera tester, felhantering, edge cases
- Bör referera TRD:s icke-funktionella krav (prestanda, säkerhet)
Dåliga acceptanskriterier:
- “Autentisering fungerar”
- “Förbättra prestanda”
- “Gör det säkert”
Bra acceptanskriterier:
- “POST /api/signup returnerar 201 + JWT-token när giltiga credentials tillhandahålls”
- “API-svarstid <300ms (p95) under 100 samtidiga förfrågningar”
- “Lösenord hashade med bcrypt kostnad 12, aldrig lagrade i klartext”
Hur man bryter ner en plan i backlog-objekt
Din plan.md säger:
## Nu
- [ ] Bygg email/password-autentisering
- [ ] Lägg till OAuth (Google, Microsoft)
- [ ] Implementera rollbaserad åtkomstkontroll
Det är tre vaga punkter. Bryt nu ner var och en i granulära backlog-objekt:
Autentisering → 6 backlog-objekt
- AUTH-001: Email/password-registreringsflöde
- AUTH-002: Email/password-inloggningsflöde
- AUTH-003: Lösenordsåterställning via email
- AUTH-004: Emailverifieringsutmaning
- AUTH-005: OAuth-registrering/inloggning (Google)
- AUTH-006: OAuth-registrering/inloggning (Microsoft)
Rollbaserad åtkomstkontroll → 4 backlog-objekt
- RBAC-001: Definiera rollschema (admin, användare, gäst)
- RBAC-002: Middleware: Kolla användarroll före skyddade rutter
- RBAC-003: Admin dashboard: Tilldela/återkalla roller
- RBAC-004: Auditlogg: Spåra rolländringar
Nu har du 10 konkreta uppgifter med tydlig scope. Var och en kan tilldelas, uppskattas och verifieras.
status.md: Den enda sanningskällan
Din status.md-fil är projektets hjärtslag. Den besvarar: “Vad händer just nu?”
Till skillnad från en Kanban-tavla (som visar uppgiftsstatus) visar status.md projekthälsa: fokus, risker, artefakter och öppna frågor.
Mall
# Status
## Fokus
Vad vi jobbar på denna vecka/sprint.
## Risker
Vad kan spåra ur oss? Vad blockerar framsteg?
## Artefakter
Länkar till färdigt arbete: ADR:er, dokument, deployade funktioner, rapporter.
## Öppna frågor
Vad är osäkert? Vilka beslut väntar?
## Ändringslogg
Senaste uppdateringar (nyaste först).
Verkligt exempel
# Status
## Fokus
- Slutför email/password-auth (AUTH-001, AUTH-002)
- Deployer till staging för säkerhetsgranskning
- Dokumenterar API-endpoints i OpenAPI-spec
## Risker
- OAuth Google-godkännande försenat (skickade in för 3 dagar sedan, inget svar ännu)
- Mitigering: Kan lansera med email/password endast, lägga till OAuth i v1.1
- Bcrypt-hashing långsammare än förväntat (400ms per förfrågan)
- Undersökning: Profilera kod, överväg att sänka kostnadsfaktor till 10
## Artefakter
- [ADR-003: JWT Token-strategi](/.assistant/adr/ADR-003.md)
- [API-dokumentation (v1 utkast)](https://docs.example.com/v1)
- [Säkerhetsaudit-checklista](https://docs.google.com/spreadsheets/...)
## Öppna frågor
- F: Ska sessionutgång vara 24 timmar eller 7 dagar?
- Kontext: TRD säger 24h, men användartestning föreslår folk förväntar sig längre
- Beslut behövs senast: Fredag (före deployment)
- F: Behöver vi CAPTCHA på registrering för att förhindra bot-missbruk?
- Forskning: Analysera registreringsmönster i beta, bestäm nästa sprint
## Ändringslogg
- **2026-03-10:** AUTH-001 komplett, mergad till main (PR#42)
- **2026-03-09:** Upptäckte bcrypt-prestandaproblem, skapade PERF-001
- **2026-03-08:** Startade arbete på AUTH-002 (inloggningsflöde)
Varför status.md fungerar
För ensamma utvecklare: Du återvänder till projektet efter en vecka och kommer ihåg exakt var du lämnade på 30 sekunder.
För team: Alla läser en fil för att veta vad som händer, vad som blockar, vad som behöver beslut.
För intressenter: Icke-tekniska personer kan kolla status utan att läsa JIRA-tickets eller tolka kryptiska commit-meddelanden.
För onboarding: Nya teammedlemmar läser status först, sedan backlog, sedan kod. De förstår kontext innan de rör implementering.
Sessionsbaserad spårning: Kickoff → Arbete → Avslut
Varje arbetssession följer ett mönster:
Sessionskickoff (5 minuter)
Innan du kodar, kolla:
- Läs status.md: Vad är det nuvarande fokuset?
- Välj ett backlog-objekt: Vad jobbar jag på idag?
- Uppdatera status: Lägg till dagens fokus i
status.md
Gör arbetet (80% av sessionen)
Bygg, testa, committa. Referera backlog-ID:n i commits:
git commit -m "AUTH-001: Lägg till emailvalidering till signup-endpoint"
Nu spåras din commit-historik tillbaka till backlog-objekt, som spårar till TRD.
Avslutning (10 minuter)
Innan du stoppar:
- Uppdatera backlog-objekt: Checka av slutförda acceptanskriterier
- Uppdatera status.md-ändringslogg: Notera framsteg, beslut, blockerare
- Skapa ADR vid behov: Tog du ett arkitektoniskt beslut? Dokumentera det.
- Markera komplett eller pågående: Flytta uppgifter i backlog.md
Denna disciplin förhindrar “Jag tror jag slutförde det…?”-tvetydighet tre veckor senare.
Verkligt exempel: Bryta ner en funktion
Låt oss gå igenom implementering av “Lösenordsåterställning via email.”
1. Börja med planobjekt
## Nu
- [ ] Lösenordsåterställning via email
2. Skapa backlog-objekt
## AUTH-003: Lösenordsåterställning via email
**Status:** Att göra
**TRD Ref:** Sektion 4.4 (Lösenordshantering)
**Prioritet:** Hög
**Arbete:** 2 dagar
**Beroenden:** AUTH-001 (registrering måste existera först)
### Beskrivning
Tillåt användare att begära lösenordsåterställning via email med säkert tokenbaserat flöde.
### Acceptanskriterier
- [ ] POST /api/reset-request med email skickar återställningslänk (om konto finns)
- [ ] Återställningstoken: 32-byte random, utgår om 1 timme, engångsanvändning
- [ ] Token lagrad i DB med användar-ID + utgångstimestamp
- [ ] Email innehåller länk: https://app.example.com/reset?token=...
- [ ] GET /reset?token=... validerar token, visar lösenordsåterställningsformulär
- [ ] POST /api/reset med token + nytt lösenord uppdaterar användarlösenord
- [ ] Använda/utgångna tokens returnerar 400-fel
- [ ] Rate limit: max 3 återställningsförfrågningar per email per timme
- [ ] Flash "lösenordsåterställning lyckades"-meddelande efter slutförande
### Utanför scope
- Flerspråkiga emailmallar (FEAT-099)
- SMS-baserad lösenordsåterställning (FEAT-100)
3. Arbeta uppgiften
Dag 1:
- Implementera POST /api/reset-request-endpoint
- Lägg till tokengeneringslogik
- Skriv enhetstester för tokenvalidering
- Commit:
git commit -m "AUTH-003: Lägg till token-generering för återställning"
Dag 2:
- Implementera POST /api/reset-endpoint
- Emailintegration (SendGrid)
- Integrationstester
- Uppdatera
status.md: “AUTH-003 komplett, deployad till staging”
4. Markera komplett
Uppdatera backlog.md:
## AUTH-003: Lösenordsåterställning via email ✅
**Status:** Klart (2026-03-11)
**Deployad:** Staging (2026-03-11), Produktion (2026-03-12)
Nu är det spårbart. Sex månader senare frågar någon “När lade vi till lösenordsåterställning?” Du greppar efter AUTH-003 och hittar commits, statusuppdateringar, deploymentdatum.
Vanliga misstag (och hur man fixar dem)
Misstag 1: Vaga acceptanskriterier
Dåligt: “Funktionen fungerar korrekt” Bra: “API returnerar 200-status, JWT-token i response body, lösenord hashat med bcrypt”
Var alltid tillräckligt specifik att någon annan kan verifiera det utan att fråga dig.
Misstag 2: För många pågående uppgifter
Problem: 5 uppgifter vid 80% slutförande, 0 uppgifter vid 100%
Lösning: Arbeta på en uppgift i taget tills den är helt klart (alla acceptanskriterier uppfyllda). Gå sedan vidare till nästa.
Använd status.md för att tvinga detta: “Fokus: Slutföra AUTH-001 innan start AUTH-002.”
Misstag 3: Aldrig uppdatera status
status.md är värdelös om den är gammal. Uppdatera den i slutet av varje session, även om uppdateringen är: “Inga framsteg idag på grund av produktionsincident.”
Misstag 4: Ingen TRD-spårbarhet
Varje backlog-objekt bör referera TRD:n. Om det inte gör det, fråga: “Bygger vi något ingen frågat efter?”
Föräldralösa funktioner är #1-källan till scope creep.
Verktyg du behöver (Spoiler: Bara markdown)
Du behöver inte JIRA, Trello, Asana eller Monday.com. Du behöver:
- backlog.md — Lista över uppgifter med acceptanskriterier
- status.md — Nuvarande fokus, risker, artefakter, frågor
- plan.md — Nu/Nästa/Senare-prioriteringar
- Git — Versionskontrollera din planering bredvid din kod
Det är allt. Inga dyra verktyg. Inga integrationer att underhålla. Bara markdown-filer i din repo.
När du behöver referera en uppgift, länka den:
Se [AUTH-003](/.assistant/backlog.md#AUTH-003) för detaljer.
När du behöver spåra uppgiftsstatus i commits:
git log --grep="AUTH-003"
Enkelt. Hållbart. Portabelt.
Prova själv
Välj ett objekt från din nuvarande “Nu”-lista. Bryt ner det i ett backlog-objekt:
- Tilldela ett unikt ID
- Referera TRD-sektionen
- Ställ in prioritet och arbete
- Skriv 5-7 acceptanskriterier (specifika, testbara)
- Notera vad som uttryckligen är utanför scope
Arbeta sedan med det:
- Uppdatera status.md med ditt fokus
- Checka av kriterier när du slutför dem
- Committa med backlog-ID
- Uppdatera status.md när klart
Det är en komplett cykel. Gör nu detta för varje uppgift. Du kommer aldrig fråga “Vad höll jag på med igen?” eller “Är detta faktiskt klart?”
Kommer i Del 5: Varför vi dokumenterar beslut (och hur ADR:er sparar tid) — Lär dig vad Architecture Decision Records är, hur man skriver dem utan att sakta ner, och varför de hindrar team från att omförhandla samma beslut sex månader senare.
Nyckelord: backloghantering, acceptanskriterier, uppgiftsspårning, agil planering, statusspårning, projektframsteg