5 exercises — OKRs vs. KPIs, SAFe Program Increments, DORA metrics, the SPACE framework and WIP limits, and meeting vocabulary like AoB and WoW.
0 / 5 completed
1 / 5
A quarterly planning doc contrasts "OKRs" with "KPIs." What's the difference between these two goal-tracking abbreviations?
OKRs vs. KPIs is a commonly confused pair because both are "goals expressed as numbers," but they serve different purposes and often coexist within the same organisation.
OKRs are typically set per quarter (or another fixed cycle), intentionally ambitious (a "good" OKR completion rate is often considered 70%, not 100% — hitting 100% every time may mean the goals weren't ambitious enough), and used to drive focused, time-boxed initiatives.
KPIs are ongoing, continuously monitored metrics that indicate whether a system or process is healthy — they don't have a "target quarter," they're tracked indefinitely, and a sudden KPI change (e.g. churn spiking) is itself the signal, rather than the KPI being a stretch goal.
A team might use a KPI ("uptime") as an ongoing health metric while also setting an OKR ("reduce P1 incidents by 50% this quarter") as a time-boxed initiative aimed at improving that same underlying area.
2 / 5
A Scaled Agile organisation refers to "planning our next PI" during a "PI Planning" event. What does PI stand for in this context, and how does it relate to a normal sprint?
PI (Program Increment) is specific to SAFe (Scaled Agile Framework), the most common framework for coordinating Agile practices across many teams (sometimes hundreds of engineers) working on interdependent parts of a larger system.
Why PI Planning exists: individual team sprints work well for a single team's own backlog, but when multiple teams' work is interdependent (Team A's API must ship before Team B can build on it), sprint-level planning alone doesn't surface those cross-team dependencies early enough. PI Planning is a dedicated, often in-person, multi-day event where all teams in a program map out their next 8-12 weeks together, explicitly identifying and negotiating dependencies before the increment begins.
This is a good example of vocabulary that only makes sense once you understand the organisational scale it addresses — a single small team would never need "PI Planning," since coordination overhead at that scale would outweigh the benefit; it becomes valuable specifically when many teams' work is tightly coupled.
3 / 5
A DevOps team reviews their "DORA metrics" in a quarterly retrospective. What does DORA stand for, and what category of metrics does it refer to?
DORA (from the DevOps Research and Assessment group, whose work is summarised in the well-known "Accelerate" book and the annual State of DevOps Report) established four metrics as empirically correlated with software delivery performance and, ultimately, organisational outcomes:
• Deployment frequency — how often code is deployed to production • Lead time for changes — how long from code committed to code running in production • Change failure rate — what percentage of deployments cause a failure requiring remediation • Time to restore service — how quickly the team recovers from a production incident
"DORA metrics" is now standard vocabulary in engineering leadership and platform engineering conversations for benchmarking delivery performance objectively, rather than relying on anecdote or gut feeling about "how fast are we shipping."
4 / 5
An engineering culture document references "the SPACE framework" for measuring developer productivity, contrasted with just tracking "WIP limits." How do these two concepts relate?
Understanding how a broad framework (SPACE) relates to a specific tactical practice (WIP limits) it can encompass is a useful skill for engineering-culture conversations, since these terms are often mentioned together without the relationship being made explicit.
SPACE was proposed specifically as a corrective to the common mistake of measuring developer productivity with a single, easily-gamed metric like lines of code or commit count. It argues productivity should be assessed across five distinct dimensions, since optimising for only one (e.g. Activity) can actively harm others (e.g. Satisfaction, if it drives burnout).
WIP (Work In Progress) limits, borrowed from Kanban and lean manufacturing, cap how many items can be "in progress" simultaneously on a board, forcing a team to finish existing work before starting new work — this directly targets flow efficiency (less context-switching, faster individual task completion), one concrete lever within SPACE's "Efficiency and flow" dimension rather than a standalone competing philosophy.
5 / 5
A retrospective facilitator writes on the board: "AoB" at the end of the agenda, alongside a note about the team's "WoW." What do these two abbreviations mean in this context?
AoB (Any Other Business) is common meeting-agenda vocabulary (not exclusive to Agile) — a deliberate, bounded slot at the end of an agenda for unplanned but relevant topics, preventing meetings from either running long chasing tangents mid-discussion or leaving legitimate concerns unraised entirely.
WoW (Ways of Working) is genuinely Agile/team-culture-specific vocabulary — it refers to the collective, often informally-agreed set of practices a team follows: their Definition of Done, their branching strategy, how strictly they follow sprint ceremonies, their code review SLA, and similar operational norms. Retrospectives frequently include an explicit "should we change our WoW?" discussion, distinct from simply discussing what went well/poorly in the last sprint — it's specifically about the team's own process rules, which are expected to evolve over time as the team learns what works for them.
Both abbreviations are common in meeting notes and retrospective templates, and recognising them quickly avoids the awkwardness of asking "wait, what does that mean?" mid-meeting.
What will I practice in "Agile Abbreviations — IT Abbreviations Exercises"?
This is an IT Abbreviations exercise set. It walks through 5 scenario-based multiple-choice questions built around real usage of IT Abbreviations terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 5 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the IT Abbreviations vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more IT Abbreviations exercises?
See the IT Abbreviations exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — IT Abbreviations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.