Book 15 · Cheat sheet

Teams & Process

How software teams plan and ship work together: Agile, Scrum, Kanban, sprints, user stories and the rituals around them.

01Acceptance Criteria: Acceptance criteria are the specific, testable conditions a single user story or backlog item must meet before the Product Owner accepts it as complete.
Acceptance criteria are pass-or-fail conditions for one specific story.
They are agreed before development starts, usually during refinement.
Common formats are rule checklists and Given-When-Then scenarios.
02Agile: Agile is an approach to software development that delivers working software in small, frequent increments and adjusts plans based on regular feedback.
Agile is a mindset and a set of principles, not a single prescribed process.
The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change.
Work is delivered in small increments so feedback arrives early.
03Burndown Chart: A burndown chart is a graph that shows how much work remains in a sprint or release over time, so a team can see at a glance whether it is on track to finish.
A burndown chart plots remaining work against time.
An ideal line from the total to zero shows the required pace.
Flat stretches suggest blocked work; upward jumps mean added scope.
04Bus Factor: The bus factor is the smallest number of people who would have to leave a project suddenly before it stalls because nobody left knows its critical parts.
The bus factor counts how many people a project can lose before it stalls.
A bus factor of 1 means critical knowledge lives in one person's head.
Pairing, code review, rotation, and documentation raise it.
05Code Smell: A code smell is a surface sign in code that often points to a deeper design problem, even though the code still works.
A code smell is a sign of a likely design problem, not a bug.
Kent Beck coined the term; Fowler's Refactoring (1999) popularized it.
Long methods, duplication and long parameter lists are classic smells.
06Daily Standup: A daily standup is a short daily meeting, usually 15 minutes or less, where a team checks progress toward its goal, plans the day, and raises blockers.
A daily standup is a short, daily coordination meeting of 15 minutes or less.
In Scrum it is called the Daily Scrum and focuses on the sprint goal.
Blockers are raised in the meeting and solved afterward.
07Definition of Done: The Definition of Done is a shared checklist of quality standards that every piece of work must meet before a team can consider it complete.
The Definition of Done is a shared quality checklist that applies to all work.
It makes done mean the same thing to everyone on the team.
Work that doesn't meet it is not part of the increment.
08Epic: An epic is a large body of work in Agile that is too big to finish in one sprint, so the team breaks it down into smaller user stories delivered over time.
An epic is work too large to finish in one sprint.
Epics are split into user stories that each deliver a slice of value.
The difference between an epic and a story is size, not format.
09Extreme Programming: Extreme Programming is an Agile method built on engineering practices such as pair programming, test-driven development, and continuous integration.
XP is an Agile method centered on engineering practices.
Key practices include pair programming, TDD, continuous integration, and refactoring.
Iterations are short and releases are small and frequent.
10Kanban: Kanban is an Agile method that visualizes work on a board of columns and limits how many items can be in progress at once to keep work flowing smoothly.
Kanban shows each piece of work as a card on a board of columns.
Work-in-progress (WIP) limits cap how many items each stage can hold.
Work is pulled when there is capacity, not pushed on a fixed schedule.
11Lean Software Development: Lean software development applies lean manufacturing ideas to software, aiming to deliver customer value quickly by removing waste and improving flow.
Lean software development adapts lean manufacturing ideas to software.
Its main goal is delivering customer value quickly by removing waste.
Common software wastes include waiting, handoffs, unused features, and defects.
12Mob Programming: Mob programming is a practice in which a whole team works on the same task, at the same time, on one shared computer, taking turns at the keyboard.
The whole team works on one task at one computer at the same time.
A driver types while navigators decide what to write.
Roles rotate every few minutes so everyone takes turns.
13MVPMinimum Viable Product: An MVP is the simplest version of a product that real users can use, built to test a key assumption and learn as much as possible with the least effort.
An MVP is built to learn whether an idea works, not to be a finished product.
It focuses on testing the riskiest assumption with the least effort.
Minimum means small scope, but viable means it must still be usable and valuable.
14Open Source: Open source software is software whose source code is published under a license that lets anyone use, study, modify and share it.
Open source code can be used, studied, modified and shared under its license.
The term dates from 1998; the free software movement began in 1983.
Linux, Git, Python, Kubernetes and React are open source.
15Pair Programming: Pair programming is an Agile technique in which two developers work together on the same code, with one typing while the other reviews and guides the work.
Two developers work on the same code at the same time.
The driver writes the code, while the navigator reviews and plans ahead.
Partners switch roles regularly to stay engaged.
16Planning Poker: Planning poker is a team estimation technique in which members privately pick estimate cards for a task, reveal them at once, then discuss the differences.
Planning poker is a team technique for estimating effort.
Everyone chooses a card privately and reveals at the same time.
Cards follow a growing sequence such as 1, 2, 3, 5, 8, 13.
17Product Backlog: The product backlog is a single ordered list of everything a team might do to improve a product, such as features, fixes, and technical work.
The product backlog is a single, ordered list of work for one product.
The Product Owner is accountable for its content and order.
Top items are small and ready; lower items are larger and less detailed.
18Product Owner: The Product Owner is the Scrum accountability responsible for maximizing a product's value by deciding what to build next and ordering the product backlog.
The Product Owner is accountable for maximizing the product's value.
They own the product goal and the order of the product backlog.
The role is one person, not a committee.
19Proof of ConceptPoC: A proof of concept (PoC) is a small, quick experiment built to show that an idea or technology can work in practice before investing in building it properly.
A PoC is a quick experiment proving an idea can work.
It targets the riskiest question with the least code possible.
Clear success criteria and a timebox make it decisive.
20Retrospective: A retrospective is a team meeting held at the end of each sprint to reflect on how the team worked and agree on concrete ways to improve next time.
A retrospective focuses on improving how the team works, not on the product.
In Scrum, it is the final event of every sprint.
Good retros end with a few concrete action items that have owners.
21Scrum: Scrum is an Agile framework in which a small team delivers a product in fixed-length cycles called sprints, using defined roles, events, and artifacts.
Scrum is a framework for applying Agile, not a complete methodology.
The three accountabilities are Product Owner, Scrum Master, and Developers.
Work happens in sprints of one month or less, most often two weeks.
22Scrum Master: The Scrum Master is the Scrum accountability that helps a team and its organization use Scrum well by coaching, facilitating events, and removing impediments.
The Scrum Master helps the team and organization use Scrum effectively.
Core duties are coaching, facilitating, and removing impediments.
The role leads by serving, not by assigning tasks or managing people.
23SDLCSoftware Development Life Cycle: The software development life cycle (SDLC) is the sequence of stages software goes through: planning, design, building, testing, release and maintenance.
The SDLC is the series of stages software goes through.
Stages: planning, requirements, design, implementation, testing, deployment, maintenance.
Waterfall, V-model, spiral and agile arrange the stages differently.
24Software License: A software license is the legal permission that says how software may be used, modified and distributed; open source licenses can be permissive or copyleft.
A license states how software may be used, modified and distributed.
Without a license, code is all rights reserved by default.
Permissive licenses (MIT, BSD, Apache 2.0) require keeping notices.
25Spike: A spike is a short, timeboxed investigation an Agile team does to answer a question or reduce uncertainty before committing to build a feature.
A spike answers a question or reduces risk; it doesn't ship a feature.
Every spike has a clear question, a timebox, and an expected output.
The term comes from Extreme Programming's spike solutions.
26Sprint: A sprint is a fixed-length period of one month or less, often two weeks, in which a Scrum team works toward one goal and produces a usable product increment.
A sprint has a fixed length of one month or less, most often two weeks.
Every sprint has one sprint goal that explains why the work matters.
Sprint events are planning, the daily scrum, the sprint review, and the retrospective.
27Sprint Planning: Sprint planning is the Scrum event that starts each sprint, where the team agrees on a sprint goal, selects backlog items it can finish and plans the work.
Sprint planning opens each sprint in Scrum.
It sets a sprint goal and selects backlog items to complete.
The developers plan the how and own the sprint backlog.
28Story Points: Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
Story points measure relative size, not hours or days.
They combine the amount of work, complexity, and uncertainty.
Fibonacci-like scales such as 1, 2, 3, 5, 8, 13 are common.
29Timeboxing: Timeboxing is setting a fixed maximum time for an activity in advance and stopping when it runs out, keeping work focused and forcing decisions about scope.
Timeboxing fixes a maximum time for an activity in advance.
When time runs out, you stop and decide what to do next.
Scrum sprints and events, spikes and Pomodoros are timeboxes.
30User Story: A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
A user story describes a need from the user's point of view, not a technical design.
The common template is: As a [user], I want [goal] so that [reason].
Acceptance criteria define when a story is complete.
31Velocity: Velocity is the amount of work an Agile team completes in one sprint, usually the total story points of finished items, used to forecast future sprints.
Velocity is the total estimate of work completed in one sprint.
Only items that meet the Definition of Done count.
An average of recent sprints is used to forecast future work.
32Waterfall: Waterfall is a sequential approach to software development in which requirements, design, building, testing, and release happen one after another.
Waterfall runs a project in fixed, sequential phases.
Each phase must be finished and approved before the next one starts.
Detailed requirements and design are written up front.