Stacks and Sprints A to Z

I agree, or I support this.

Showing two versions to comparable groups to see which performs better.

The conditions a story must meet to count as done.

How usable the software is for people with disabilities.

Overall share correct, share of flagged items that were right, and share of true items that were found.

Acknowledged, and not acknowledged or rejected.

First meaningful use, continued use over time, and the share of users who stop.

A short record of a technical decision, its context and its consequences.

As far as I know, if I recall correctly, in my opinion.

An AI system that takes actions and uses tools to complete a task over several steps.

Describes AI that plans and acts across several steps with some autonomy.

A family of methods that deliver in short cycles and adjust as they learn.

Software that performs tasks associated with intelligence, and the approach of learning patterns from data.

Early internal testing, wider testing with known gaps, and full release.

Studying a decision so long it never gets made.

Removing identity from data for good, or replacing it with a code that can be linked back.

A translation layer that stops an old system’s messy model leaking into a new one (Evans, 2003)

A defined way for one piece of software to ask another for data or actions.

A secret code that identifies a program calling an API.

Designing for integration, small screens or no connection before anything else.

The two verdicts a reviewer can give.

Designs how a system, or an organisation’s systems, fit together.

A tamper-resistant record of who did what, and when.

Proving who you are.

Deciding what you’re allowed to do once signed in.

Adding or removing servers automatically as demand changes.

The share of time the system is up and usable.

The servers, databases and logic users never see.

Loading historical data into a new system.

The ordered list of work not yet started.

A copy of data kept for recovery.

A change that keeps older integrations and data working.

Capacity to take on more work.

How much data a connection can carry per second. For the “no bandwidth” sense, see B12.

Tools and reports that turn data into dashboards for decisions.

A system with no discernible structure, grown by patch on patch (Foote & Yoder, 1997)

Replacing everything at once in a single cutover.

Spending most time on trivial decisions everyone can weigh in on.

Software decaying as everything around it changes.

A view showing who last changed each line. Neutral, despite the name.

How much breaks if this change goes wrong.

Work that can’t move until something else happens, and the thing in the way.

Running old and new versions side by side, then switching traffic over.

The standard statuses a ticket moves through.

Repetitive set-up code that every project needs. For the editorial sense, see Marks and Measures B3.

A boundary within which a term has exactly one meaning (Evans, 2003)

A separate line of work that can change without affecting the main code.

Putting a stable interface in front of the part to be replaced, then swapping what’s behind it.

A change that stops existing integrations or behaviour working.

Adding people to a late software project makes it later (Brooks, 1975).

The app that displays web pages: Chrome, Safari, Edge, Firefox.

A fault that makes software behave in a way it shouldn’t.

A session where everyone hunts for bugs, and a short event to build something new.

Turning source code into software that can run. Also the result.

Deciding whether to develop software or procure a product.

A chart of work remaining against time in a sprint.

How many people could leave before nobody understands a system.

Turns business needs into requirements.

A stored copy of data kept close at hand for speed.

Releasing to a small group first to catch problems early.

Common ways a ticket is closed without a code change.

Forecasting the resources needed for expected demand.

Copying the rituals of successful teams without the reasons behind them.

Servers around the world that hold copies of content close to users.

A record of what changed in each version, for engineers or for users.

Deliberately breaking parts of a live system to prove it can cope.

Copying one specific change from one branch to another.

Automation that builds and tests every change, then delivers it towards release.

Temporarily stopping calls to a failing service so the failure doesn’t spread (Nygard, 2007)

A template for a kind of thing in code, and one instance of it.

The user’s device or app that asks, and the computer that answers.

Copying a repository to your machine, or into a separate copy you own.

Computing rented from a provider over the internet, such as AWS, Azure or Google Cloud.

Content management, customer relationship management and enterprise resource planning systems.

A period when no changes may be released.

Another engineer reads and comments on a change before it is merged.

A surface sign that the design underneath has a problem.

How well the code in one part belongs together. High cohesion is the goal.

A group of users who share a starting point, such as everyone who joined in March.

A note in code for humans, ignored by the computer.

One saved change, with a message explaining it.

Translating code into a form the computer runs directly.

How many moving parts and paths the code has.

Settings kept outside the code so they can change without rewriting it.

A packaged app with everything it needs to run anywhere. Docker is the common tool.

Designs the words in an interface.

How much text a model can take in at once.

Systems mirror the communication structure of the organisation that builds them (Conway, 1968).

A small file a website stores in your browser, and the period you stay logged in.

An AI assistant built into another tool.

Browser rules on which sites may request data from which servers.

Ready-made software bought rather than built.

How tightly parts depend on each other. Loose coupling is the goal.

A formal request to change agreed scope, cost or schedule.

The program stops unexpectedly.

Other plain-text data formats: tables, tagged documents and settings files.

Chief technology officer, chief information officer and chief information security officer.

The moment users switch from the old system to the new.

A public catalogue number for a known vulnerability.

Deploying a feature to production but keeping it hidden from users.

A screen of live charts showing system health.

Answers questions from data, and builds models to predict or explain.

Unauthorised access to or release of data.

Definitions of every field, and an index of the datasets an organisation holds.

Builds the pipelines that move and store data.

Where data came from and every change it went through on the way.

The person accountable for a dataset, and the person who looks after it day to day.

The automated route data takes from source systems into a store for analysis.

Where data is physically stored, and under which country’s law.

The kind of value a field holds: string (text), integer (whole number), boolean (true or false), null (empty)

A structured store organised for reporting, and a large store of raw data in many formats.

Organised, stored data the system reads and writes.

A defined collection of data used together.

Daily and monthly active users.

Code that never runs but is still kept.

A project everyone knows will fail, pushed on regardless.

Working, but slower or with some features failing.

Outside code a project relies on. Two meanings: also a task that waits on another (B9)

Work that must wait on other work. Two meanings: also outside code a project uses (B2)

Conflicts between the versions of outside code a project needs.

Putting a build onto an environment’s servers.

Still works but scheduled for removal. Stop using it.

How easy and pleasant a tool, platform or API is for engineers to use.

Builds the tools and pipelines other engineers use to ship.

The exact lines added and removed between two versions.

The team’s standing checklist for finished work, and for work ready to start.

Using your own product internally before customers do.

The browser’s live model of a page, which code changes to update what you see.

Designing software around the real-world domain and its experts’ language (Evans, 2003)

A web address, and the system that turns it into a server location.

Four measures of delivery performance: deployment frequency, lead time for changes, change failure rate and time to restore service.

Oversees an organisation’s compliance with data protection rules.

The plan and systems for restoring service after a major failure.

A pull request opened early to show work in progress, not yet ready for review.

“Don’t repeat yourself”: keep one copy of each piece of logic (Hunt & Thomas, 1999)

An unusual situation at the limits of normal use, or where two limits meet.

Text turned into numbers that capture meaning, and a store for searching by meaning.

Scrambling stored data, and scrambling data as it travels.

A test of a whole user journey, start to finish.

One specific address on an API, such as the one that returns a class list.

Manages engineers’ work, growth and hiring.

A separate copy of the system for one purpose. Two meanings: see Part C.

A setting supplied by the server where code runs, often a secret such as a key.

A large body of work split into many stories.

The amount of failure an SLO allows before releases must slow down.

A failure the code detects and reports, or one that interrupts it.

A forecast of effort, not a commitment.

Structured tests of how well a model or AI feature performs.

Parts of a system react to announced events instead of calling each other directly.

What should have happened, and what did.

Code or a method that takes advantage of a vulnerability.

A simple front over complex code, a translator between two interfaces, and a cover around existing code.

Detecting and surfacing problems immediately rather than letting them compound.

A team judged by how many features it ships, not by whether they help.

A switch that turns a feature on or off without a new deploy.

A new system doing everything the old one did.

Further training a model on specific data to adapt it.

An automated test that passes and fails at random.

A feature that makes it easy to hurt yourself.

A structure of ready-made code that shapes how an app is built, such as React or Django. Two meanings: see Part C.

The part users see and touch, in a browser or app.

Specialises in the user-facing layer, the server side, or both.

Both front end and back end.

A named block of code that does one job.

The steps users take towards a goal, and the share who complete each step.

The government’s approved arrangement for running agency systems on commercial cloud.

The European Union’s data protection law.

The most widely used version control system.

Websites that host Git repositories and the reviews around them.

Adding polish or features nobody asked for.

Using one familiar tool for every problem.

The supported, recommended way to do something.

The chip that trains and runs most AI models.

Keeping core functions working when parts fail.

All automated checks passed, or at least one failed.

Building from scratch, or building on existing systems.

Data known to be correct, used to train or check a model.

Tying a model’s answers to supplied sources so they can be checked.

Rules and checks that limit what an AI system may say or do.

A model producing confident but false content.

The expected journey where everything goes right.

A value written directly into the code instead of set in configuration.

Turning data such as a password into a fixed code that can’t be reversed.

Content managed separately from the way it’s displayed, so it can appear anywhere.

Focused, not to be interrupted.

A bug that disappears when you try to observe it.

Building one layer at a time, so nothing works until every layer is done.

An urgent fix released outside the normal schedule, and a small fix in general.

The three languages of the web page: structure, appearance and behaviour.

The protocol for sending web pages and API calls. HTTPS is the encrypted version.

A person reviews or approves the AI’s output before it takes effect.

Internationalisation, building software so it can support any language, and localisation, adapting it for one. The numbers count the letters in between.

Someone senior who does the work rather than managing people.

A unique identifier for a record. A UUID is a long random one.

An action that has the same result however many times it runs. Pressing submit twice doesn’t create two entries.

Written the way the language’s community expects.

A web page displayed inside another page.

The Singapore Government’s instruction manual for managing ICT and smart systems, including security and data policies.

An unplanned interruption or degradation that needs a response.

The person who coordinates the response to a serious incident.

Code that repeats forever and never finishes.

Defining servers and networks in versioned files instead of setting them up by hand.

A working connection between two systems.

A test that parts work together correctly.

How well a system exchanges data with others.

Shaping teams deliberately to get the system design you want.

A joke defence of odd behaviour. Occasionally true.

Refining the whole thing in rounds, or adding finished pieces one at a time.

IT service management, and the team users contact for help.

A prompt designed to get a model past its safeguards.

A plain-text format for structured data, the common language of APIs.

A flag that turns a feature off instantly.

“Keep it simple”: prefer the simpler design.

A clumsy fix that works but shouldn’t be relied on.

A bug that’s acknowledged and documented but not yet fixed.

A system for running and scaling many containers. The 8 counts the letters in between.

Tiers of support: first contact, specialist help, and engineering or vendor fixes.

The delay between an action and its response.

Time from request to delivery, and time from starting work to delivery.

Giving each person or system only the access it needs.

An old system still in use, often hard to change.

“Looks good to me”: an approval.

Reusable code a program calls for one job, such as dates or charts.

Paying per user, paying for ongoing access, or paying once to own a version.

Moving a system to new infrastructure, such as the cloud, without changing it.

A tool that flags style problems and likely errors in code.

A model trained on large amounts of text to generate language, and AI that creates new content.

A platform for delivering courses, assignments and grades.

A component that spreads traffic across several servers.

Testing behaviour under expected heavy use, or beyond it until it breaks.

The engineer’s own machine, and the shared development environment.

Records of events, numbers over time, and the path of one request through the system.

Building apps with visual tools and little or no hand-written code.

A 1EdTech standard for launching external tools inside an LMS with sign-in and grades passed across.

A version supported for years, and one that gets no more fixes.

An unexplained number in code whose meaning only the author knows.

The primary branch: the code that counts.

How easily the code can be changed and fixed later.

A scheduled period for planned work, when downtime is allowed.

Harmful software, and the kind that locks data until a ransom is paid.

The authoritative core records an organisation runs on: students, staff, schools.

An open standard for connecting AI models to tools and data sources.

Memory that’s used and never released, slowing the system over time.

Joining a branch’s changes into another branch, usually main.

Two changes to the same lines that the system can’t combine on its own.

The change is in the main code. Not necessarily live: see Part C.

Data about data: who made it, when, what each field means.

Signing in with a second proof, such as a code on your phone.

An application split into many small services, each deployed on its own.

Software that connects other systems and passes data between them.

Moving data or a schema to a new structure or system. Two meanings: see Part C.

A significant, dated point in a project.

Builds and runs machine learning models in production.

Builds apps for iOS or Android.

Fake stand-ins for real parts of a system, used so a test can run in isolation.

The trained system that produces predictions or outputs.

Systematic unfairness in a model’s outputs, often inherited from its training data.

A document stating a model’s purpose, training data, performance and limits.

A self-contained file or unit of code. Two meanings: see Part C.

Watching a system’s health, and notifying people when something crosses a threshold.

One large application where all parts are deployed together.

One repository holding many projects.

The average time taken to restore service after a failure.

A model that handles text, images, audio or video.

The smallest version that can test whether the idea works with real users.

An app installed for one device type, or one that runs in a browser.

Availability as a percentage. 99.9% allows about 8.8 hours of downtime a year. 99.99% allows about 53 minutes.

A minor, optional comment, such as a naming preference.

The single measure a product team steers by.

Rejecting outside solutions because they weren’t made in-house.

A roadmap in three horizons, without fixed dates.

Two survey scores: one from “how likely are you to recommend us”, and one from how satisfied users are. For usability scores, see Marks and Measures B9.

A missing value the code didn’t expect.

A standard that lets one app access another on your behalf without your password.

How well the team can see what the system is doing from its logs and metrics.

A count or loop that is wrong by exactly one.

Objectives with measurable key results, and key performance indicators.

The engineer responsible for responding out of hours, and the alert that wakes them.

Software run on an organisation’s own servers.

A 1EdTech standard for exchanging class lists, enrolments and grades.

Code anyone may use and inspect, or code owned and licensed by a company.

A model whose trained parameters are published for anyone to run.

The base software of a device: Windows, macOS, iOS, Android.

A period when a system is unavailable.

Built for problems that don’t exist yet.

A bundle of shared code, and the tool that installs it, such as npm or pip.

Running old and new systems side by side and comparing their outputs before switching.

Singapore’s main data protection law for private-sector organisations. Public agencies follow separate government rules.

Authorised, simulated attacks to find weaknesses.

How fast and efficiently the software does its work.

Tricking people into giving away access or data.

Data that can identify a person: names, IDs, photos, contact details.

Send a short message, meet live, or work without meeting at the same time.

The automated sequence of build, test and deploy steps. Two meanings: see Part C.

A quick build to show something is technically possible.

A written review of an incident that looks for causes in the system, not the individual.

The document that sets out what a product or feature must do, and why.

Tuning for speed or scale before knowing it matters (Knuth, 1974).

How urgently a bug should be fixed.

Decides what to build and why, based on user needs and goals. Two meanings: PM also means project manager.

In Scrum, the person who owns and orders the backlog.

Fit to run for real users: tested, monitored and secure.

The live system real users rely on. Two meanings: see Part C.

The language code is written in: Python, JavaScript, Java.

Building a basic version that works everywhere, then adding richer features where supported.

Runs schedule, budget and coordination for a defined project.

Hidden instructions in content, such as a web page or document, that hijack an AI system.

The instruction given to a model, and the standing instruction set by the builder.

“Please take another look”

A proposed change, opened for review before it joins the main code.

Sending your commits to the shared repository, or fetching others’

A web app that can be installed and work partly offline.

Systematic testing to find defects before users do. Also the team that does it.

Finds defects. An SDET (software development engineer in test) writes automated tests.

A 1EdTech standard for exchanging assessment items and tests.

A request to a database for specific data.

A bug that depends on the timing of two things happening at once.

Having a model look up relevant documents before answering, so it draws on them.

A cap on how many requests a caller may make in a period.

Permissions granted by role, such as teacher, student or admin.

Investigating the underlying cause of a failure, beyond the trigger.

How easily another engineer can understand the code.

The front-page document of a repository: what it is and how to use it.

Replaying your changes on top of the latest code to keep history tidy.

Deliberately attacking a model or system to find harmful or wrong behaviour.

Spare capacity, and the switch to it when a component fails.

Restructuring code without changing what it does, to make it easier to read and change.

Clarifying and sizing backlog items before planning.

A pattern for matching text, such as a valid email address.

Something that used to work and broke after a change.

A test that old features still work after a change.

The standard options for each legacy system in a migration: move it, adjust it, rebuild it, replace it with a product, switch it off or keep it.

Making a feature available to users. Can happen after deploy, through a flag.

How consistently the system works as expected.

The stored home of a project’s code and its full history.

A message asking a server for something, and its reply.

The ability to keep working when a part fails.

Two common styles of designing an API.

How long data may be kept before it must be deleted.

A team’s review of how it worked, not what it built.

Undoing a change with a new commit that reverses it.

The person asked to review a change, and the person whose approval it needs.

A proposal circulated for feedback before a decision.

Request for information, request for quotation and request for proposal: the stages of asking the market.

A plan of what will be built over the coming months or quarters.

Holds up under unexpected input, or breaks easily.

Returning to the previous version after a bad release.

Releasing gradually: some users, then more, then all.

How much data you can afford to lose, and how long you can afford to be down.

A rude way of saying “read the manual”. Best avoided.

Explaining a problem aloud, even to a toy, until you see the answer (Hunt & Thomas, 1999)

Step-by-step instructions for handling a known situation.

The environment that actually runs the code, such as Node.js.

Software, platform or infrastructure “as a service”: how much the provider runs for you.

A safe, isolated environment for trying things without consequences.

How well a system copes as users or data grow.

The defined structure of data: which fields exist and what they hold.

Requirements growing after work has started.

An older standard for packaging e-learning content so any LMS can run it and record completion.

A short program that automates a task.

Helps a Scrum team follow its process and removes obstacles.

Two common agile methods: fixed-length sprints with set roles, or a continuous flow of work across a board.

A bundle of tools and libraries for building on a platform.

Overloading the replacement with everything left out of the first system (Brooks, 1975).

A password, key or token that grants access.

Protection against misuse, attack and data loss.

Fake data used to fill a system for development and testing.

Markup that describes what content is, such as a heading or a button, and attributes that make custom widgets accessible.

Version numbers as major.minor.patch, such as 2.4.1. A major change can break things (Preston-Werner, n.d.)

Making pages easy for search engines to find and rank.

Keeping parts that do different jobs apart, so each can change alone.

Code run by the cloud provider on demand, with no server to manage.

How serious a bug’s impact is.

How serious an incident is. Sev 1 or P1 is usually the worst.

Tools used without the IT department’s knowledge or approval.

A new system runs on real inputs, but its outputs are only compared, never used.

Moving testing, security or accessibility checks earlier in the process.

Informal: to release.

Release it. Also a cheerful approval.

One component whose failure takes everything down.

One authoritative place for each piece of data.

Singapore’s national digital identity for signing in to government services.

The system of record for enrolment, classes and student details.

A contract’s promise about availability or support, often with penalties.

The actual measurement an SLO is judged on.

An internal target for reliability, such as 99.9% of pages loading within two seconds (Beyer et al., 2016)

A quick check that the most basic functions work at all.

Writes, tests and maintains code.

The human-written instructions of a program, and the whole body of it.

What a vendor will deliver, by when and to what standard.

A web app that updates in place instead of loading new pages.

Tangled code with no clear structure.

A time-boxed investigation to answer a question before committing to build. Two meanings: in newsrooms, to kill a story.

The meeting that decides what goes into the next sprint.

Showing what was built to the people who asked for it.

A fixed period of work, usually one or two weeks.

The standard language for querying table-based databases, and databases that store data other ways.

A small, cross-functional team owning one product area.

Keeps production systems reliable using engineering methods.

One sign-in that opens many systems.

The list of code steps that led to an error, used to locate it.

The set of technologies a product is built on.

Senior technical roles that shape work across several teams.

A near-copy of production for final checks before release.

A branch left so long it no longer fits the main code.

A short daily meeting: done, doing, blocked.

A server’s numbered reply: 200 OK, 301 moved, 403 forbidden, 404 not found, 429 too many requests, 500 server error, 503 unavailable.

A public page reporting whether a service is working.

One critical user journey built end to end first, then strengthened.

A relative size for a story, combining effort and uncertainty, not hours.

Replacing a legacy system gradually, routing one function at a time to a new system until the old one can be switched off (Fowler, 2004)

Retire a product or feature.

Artificial data generated to train or test systems without using real people’s records.

Rough sizes of S, M, L and XL for early estimates.

A set of records, one record and one item within it.

A named marker on one point in history, usually a release version.

To be decided.

The full cost of a system over its life, beyond the purchase price.

Teams that own a user-facing flow, provide shared foundations, coach others, or handle specialist parts (Skelton & Pais, 2019)

The senior engineer who guides a team’s technical decisions.

The engineering plan for how something will be built.

The future cost of shortcuts taken now (Cunningham, 1992).

Usage data sent automatically by software, and one recorded user action.

A setting for how varied or predictable a model’s output is.

A formal, competitive invitation to bid for a contract.

The share of code exercised by automated tests.

How easily the code can be checked automatically.

A small piece of functionality built through every layer, so it works end to end.

A structured look at who might attack a system, how and what to protect.

Deliberately slowing or limiting requests to protect a system.

How much work a system handles in a given time.

Hand work to another team without context or support.

A tracked record of a bug, request or task.

A fixed amount of time allowed for an activity, after which it stops.

An operation that took too long and was abandoned.

A recorded date and time, the world reference time, and the standard way to write dates (2026-10-02)

“Too long; didn’t read”: the summary follows.

The encryption behind HTTPS. SSL is the older name, still widely used.

Repetitive manual operations work that could be automated (Beyer et al., 2016)

A chunk of text a language model reads or writes, roughly part of a word. Two meanings: also a credential that grants access (B6)

Working end-to-end code built early to check the aim, then kept and grown. Unlike a prototype, it isn’t thrown away (Hunt & Thomas, 1999)

Building a model from data, and using the finished model to produce outputs.

Sorting new bugs by severity and priority, and assigning them.

Everyone merges small changes into the main code often, instead of keeping long-running branches.

A team small enough to be fed by two pizzas.

JavaScript with added type checking, which catches errors earlier.

Testing by real users or business owners to confirm the software meets their needs.

One shared vocabulary used by domain experts and engineers in conversation and in code (Evans, 2003)

The standard that covers every writing system, and its most common encoding.

An automated test of one small piece of code on its own.

Time a system is working, and time it isn’t.

A web address.

A small requirement written from a user’s view: as a teacher, I want... so that...

Designs how a product works and feels, how it looks, or both.

Studies users to inform what gets built.

The combined security testing required before systems go live.

A named container for a value that can change.

How many points a team usually completes in a sprint. A planning aid, not a performance score.

Dependence on one supplier that makes switching costly.

An outside supplier, and a firm hired to build and connect systems.

A system that records every change to code, who made it and why.

Building software by prompting an AI and accepting its code without close review.

A simulated computer running inside a real one.

A weakness that could be exploited.

The thinnest working version of the whole system, with all main parts connected, built before any features (Cockburn, 2004)

Delivering in fixed phases, each finished before the next begins.

An automatic message one system sends another when something happens.

Work in progress: not ready for review.

A cap on how many items can be in progress at once.

A way to get the job done despite the bug.

A bug the engineer can’t reproduce locally. Usually said ruefully.

A standard for recording learning activity as statements, and the store that holds them.

“You aren’t gonna need it”: don’t build for imagined futures.

A chain of side tasks needed before the real task can start.

A vulnerability attackers know about before a fix exists.

Asking a model to do a task with no examples, or with a few examples in the prompt.