Mål att sträva mot under projektet. Några av målen kan nås direkt, andra kan ta tid att få ordning på. I slutet av projektet bör alla målen vara uppfyllda.

• Teamarbete Det är bra stämning i teamet. Alla hjälps åt och arbetar mot målen som listas här, samt mot egna mål som teamet definierar själv. Alla gör sina uppgifter ansvarsfullt, både vad gäller det individuella spike-arbetet och arbetet under planeringsmöten och långlabbar.
• Parprogrammering Alla i teamet har parprogrammerat med alla andra och partners byts regelbundet. Alla praktiserar "riktig" parprogrammering där både driver och navigator är aktiva och byter roller ofta, och där man arbetar enligt "seven habits": take breaks, practice humility, be confident/be receptive, communicate, listen, be a team player, hone the balance between compromising and standing firm.
• Test-driven utveckling Utveckling av testfall och produktionskod görs enligt "test-driven utveckling" i mycket små inkrement: skriv ett testfall, kontrollera att det inte går igenom, skriv produktionskod för att få testfallet att fungera, refaktorisera vid behov så att kodkvaliteten hålls hög, skriv nytt testfall, osv. Det skall finnas automatiserade testfall för i stort sett all produktionskod.
• Kodkvalitet Koden har hög kvalitet: den är lättläst med god och konsistent namngivning. Den är enkel i XP's mening och har inte "dåliga lukter" som t.ex., kodduplikation, spekulativa generaliseringar, långa metoder, många parametrar till metoder, etc. Alla kan refaktorisera koden vid behov och kommunicera med andra i teamet så att ingen annan i teamet blir missnöjd med refaktoriseringarna. Koden ägs gemensamt.
• Clean repository Alla kan hålla repositoriet rent, dvs committa på så sätt att en utcheckning av senaste version alltid kan kompileras och testas utan fel. Alla committar ofta och kommunicerar bra så att merge-konflikter blir få och små.
• Verktyg Alla kan använda verktygen som Eclipse, versionshanteringssystem, wikis, junit, etc. utan problem.
• Story done Teamet har en tydlig process för hur man jobbar med en story, t.ex. angående task-indelning, test, dokumentation, och när den bockas av som helt färdig.
• Releaseprocess Teamet har en enkel och tillförlitlig release-process. Det går snabbt att konstruera en ny fungerande release till kunden. Alla i teamet behärskar denna process.
• Arkitektur Alla i teamet har en gemensam bild av hur den nuvarande versionen av programmet är uppbyggd. Man har en gemensam vokabulär för de olika huvudsakliga delarna. Alla vet hur man provkör produkten.
• Planering Alla i teamet vet hur långt man hunnit i projektet, dvs. vilka stories som är avklarade och vilka som är planerade. Teamet kan göra realistiska estimeringar av stories och vet ungefär hur mycket man hinner på en iteration.
• Kundsamarbete Teamet har ett gott samarbete med kunden och diskuterar med kunden så fort det finns oklarheter. Kunden är nöjd med teamets produkt.