An Agile glossary | Joseph Clift

This week, I got PMI-ACP certified, which involved taking and passing an exam. In the past couple of months, I put together this Agile glossary as a study aid. It’s an A-Z of Agile concepts, frameworks… and buzzwords. The information is based heavily on the study guide and online learning path I used. I hope it helps others studying for the exam, or can maybe be used as a more general reference tool. Each italicised term in the glossary is a reference to another listing on the glossary.

Acceptance Criteria: Conditions that must be met for value to be delivered in an Agile project. Generally these are attached to a User Story, and contain the specific terms for that particular story to meet the team’s Definition of Done. Often but not always written in the format “Given (something) when (something) then (something)”.

Active listening: Part of being a good Servant leader for the Agile project manager. An active listener doesn’t just hear the words of the person speaking to them, but focuses on these words and the meaning behind them. Equally important is that an active listener does not think about their response at this point: the focus should be on the person they’re listening to.

Adaptive leadership: This is a constant theme through Agile methodologies and frameworks and especially applies to the project manager or Scrum Master. It’s about adapting tools and techniques to your team and your environment. About modelling best practices and behaviours by doing them yourself - and leading by example. Pivoting quickly and rolling with the punches. Reflecting the Agile Manifesto’s prioritising of ‘responding to change’ over ‘following a plan’.

Adaptive Software Development: Or, ASD. An agile framework popularised in a 2000 book by Jim Highsmith. This framework replaces the traditional Waterfall process with one based on the Shewhart cycle of plan-do-check-act. This framework especially encourages rapid changes based on testing and learning.

Adkins guidelines: A set of guidelines for one-on-one coaching in an Agile environment. These are: stay half a step ahead, guarantee safety, partner with managers and create positive regard. Coaching at a team level is also encouraged during Retrospectives.

Affinity estimating: A technique for estimating User Stories, which involves a team grouping stories into categories according to the size of the story, then holding discussion for everything that doesn’t seem to fit in a category.

Agile Manifesto: Written by a team of software developers at a conference in 2001, and the basis of the whole movement. It has its roots in a shared frustration about heavyweight project management frameworks. It contains four statements, in which one thing is prioritised over another:

Individuals and interactions (over) Processes and tools
Working software (over) Comprehensive documentation
Customer collaboration (over) Contract negotiation
Responding to change (over) Following a plan

Agile Modelling (AM): This is a collection of values and principles that can be applied and added to another framework, such as Scrum or XP. It focuses on documentation - written as late as possible and stored in a single place. Given the focus on specific documentation, AM is more suited to smaller teams - it can’t really be scaled effectively as the overhead of writing and maintaining documentation increases with team size. AM has five values: A. Communication, Simplicity, Feedback, Courage, Humility.

Agile planning: Agile teams don’t give up planning, they focus on short-term planning. That’s one of the advantages of working in short Sprints, in which the team can be sure that they are only planning what needs to be delivered at the end of the next Sprint. Generally in Agile planning, the Product Owner decides what will get built and the Development team decides how it will get built. You have a flexible scope based on value, risk, cost and time - and the most detail is for the most immediate work. Rolling wave planningis a particularly popular Agile planning technique. By contrast, traditional planning is based around a fixed schedule and a fixed project scope, in which you agree on tasks and deadlines up front.

Agile Principles: The Agile Manifesto described a mindset and not a practical way of working. So the authors followed it up with a set of 12 Agile Principles. These principles fill in a lot of things that could be left to the imagination from the Agile Manifesto alone and provide a more practical guide for ways of working. The principles are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the subscriber and Which’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Product and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress. This doesn’t mean it’s the final product or fully refined product. Also includes primary measure of outcomes.
Agile processes promote sustainable development. The sponsors, product, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more efficient in delivering value, then tunes and adjusts its behavior accordingly.

Architectural spike: An XP concept that is now used by many Agile teams more generally. It can be a task within an iteration/sprint, or a short iteration between more typical iterations/sprints, involving the whole team. It involves an investigation into whether a proof of concept or technical implementation will actually work. The purpose of an architectural spike is to reduce the risk of technical problems occurring later in the project.

ASD Cycle: The process by which projects are developed and delivered in ASD, an Agile framework. The cycle is: mission focused, feature based, iterative, time-boxed, risk driven, and change tolerant.

Backlog: A list of User Stories, tasks and other work to be performed by the team. A team’s backlog doesn’t capture all the work required to deliver a product or initiative, it’s an ever-changing document. The Product Owner has overall responsibility for refining, prioritising and ordering the backlog (otherwise known as Backlog grooming), such that it delivers maximum value.

Backlog grooming: Backlog grooming includes estimating, analysing, prioritising and breaking down User Stories in a team’s Backlog. Some of these tasks can be done in a formal meeting with the team - the Backlog refinement meeting. The Product Owner is the one who ensures that, as the backlog is refined, the releases will add value for the user. Visualize the backlog as a funnel, as the stories get closer to being executed during a sprint, they move to the top of the funnel, and become more concrete.

Backlog refinement meeting: A meeting in which some or all members of an Agile team meet to refine the Backlog. Activities could include:

Product Owner prioritises the backlog or gives their reasons for this prioritisation
Product Owner makes sure Acceptance Criteria in User Stories are correct
Some stories may get thrown out, rewritten or refined. New ones may be written depending on the discussion.
User Stories may be estimated, using Planning Poker or similar techniques.

Unlike other Agile meetings - such as the Daily StanduporRetrospective, Backlog refinement meetings have no strict time limit.

Backlog prioritisation: The process by which the Product Owner orders the User Stories in the Backlog. The most important/impactful/value-adding stories are placed at the top of the backlog.

Brainstorming: A session involving some or all of the Agile team aimed at working together to meet a particular goal. An example session could be the team working through a set list of questions as part of Chartering or coming up with an Elevator Statement. Brainstorming can also be useful for flagging future risks in a project. Facilitators of these sessions commonly use prompt lists to guide the conversation, for example SPECTRUMin a session designed to flag risks. Another commonly used brainstorming framework is SWOT Analysis.

Burn down chart: A line chart that tracks work completed by an Agile team in each sprint/iteration. Typically, the chart shows one sprint at a time, and the ideal trend line is towards zero - in that there is no work remaining at the end of the sprint if everything goes perfectly. The charts further allow predictions to be made about how many iterations are needed before a particular product or initiative is done. The rate at which a team burns through their work is known as Velocity for teams using Scrum. Used carefully, these charts may indicate when a larger project is likely to be completed.

Burn up chart: A line chart that, similar to Burn down charts, tracks work completed by an agile team over time. Unlike Burn down charts, the Burn up chart shows multiple sprints/iterations over time, with the line trending upwards as more and more work is completed. In this way, a burn up chart is particularly useful for highlighting changes to project scope.

Chartering: This is a process borrowed from traditional project management that may be adapted by an Agile team. A charter is a precursor to the project beginning - something that happens at the very start of the project. An Agile charter describes the project’s goals, while admitting uncertainties; a more traditional project charter would aim to include a defined scope and timeline. At a minimum, for their charter, the Agile team must define various “why’s and how’s” concerning the project: 1) Who will be engaged in your project? 2) What will the project be about? 3) Where will the work happen? 4) When will the work happen? 5) Why is the project needed? (Business goal) 6) How will you work? (eg, framework).

The Chicken and the Pig: A fable often used to explain the difference between an Agile team and their Stakeholders: “Once upon a time there was a chicken and a pig. One day the chicken decides that the two should start a restaurant. The pig is intrigued by the idea and says, ‘That sounds great. But what are we going to call the restaurant?’ The chicken thinks. Then she suggests, ‘Ham and Eggs!’ To which the pig replies, ‘No thanks, if we’re serving ham and eggs, I’d be committed. You’d only be involved.’“ Using this analogy - Stakeholders are chickens - involved with the project but not committed. Agile team members are pigs - all in!

Co-location: Having the whole Agile team in the same (physical) space. Pre-COVID, this was thought to be an important requirement for teams to work well together. For many teams these days though, some team members will need to be remote at least some of the time, meaning that the onus is on the team to recreate co-location, and the associated benefit of Osmotic communication, as best they can using digital tools. In an office setup, co-location for an Agile team requires Commons (team work space) and Caves (small, private workrooms).

Collaboration games: These are held between the Agile team and Stakeholders. They include Prune the product tree, Sailboat, and many more. The goal in these games is to encourage participatory decision making - everyone ought to chime in with their views - and convergence (or collective agreement) between Stakeholders and the team.

Cone of Uncertainty: A concept often used by Agile teams to explain to Stakeholders why it isn’t desirable to make big promises at the start of a project. Like a cone, a project begins with a very wide range of potential outcomes, which narrow as time goes on, requirements are firmed up, the build proceeds, and the team learns things. It follows that an Agile team should only confirm requirements and scope later on in the project, when the cone is narrow enough to make such decisions safely.

Conflict resolution: There are various conflict resolution strategies open to Agile teams, including compromise, smoothing (de-emphasising differences as a short term fix when the disagreement is particularly heated), and avoiding. Generally the best strategy is to collaborate: identify the underlying problem and work out solutions in a way that allows all parties to work through their disagreements.

Continuous integration: In software engineering, continuous integration is the practice of merging all developers’ working copies to a shared mainline several times a day. This results in smaller releases that happen more often - with less chance of Defects - rather than a large “Big Bang” release at the end of the project.

Conway’s Law: A maxim that states: ‘Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure… therefore, flexibility of organization is important to effective design.’ In other words, an organisation’s work reflects how people in an organisation talk to each other - and to their customers.

Crystal: This is a set or “family” of Agile methodologies, developed by Alistair Cockburn (inventor of the User Story) in the 1990s. Crystal is most widely-known for the categorisation of its “family”, or “Crystal Methods”. These are colour coded, from Crystal Clear (small projects) to Crystal Sapphire (big, mission-critical projects). The heavier the project, the heavier the processes. But all the methods in the family share core tenets of teamwork, communication and simplicity.

Cumulative flow diagrams: A graph that provides a top-level view of how a team is progressing, tracking the status of all work items (tasks or User Stories for example) over time. The total number of items marked as DONE increases over time, and the team looks for patterns in all the other statuses (eg, TO DO or IN PROGRESS). Some guidelines for these statuses: a constant slope indicates work is moving through the system efficiently, while increases or decreases in the number of items in a status can indicate a bottleneck.

Customer value prioritisation: In Agile, what the customer values the most is the highest priority. This is customer value prioritisation. To achieve this, the Product Ownerworks with Stakeholders on prioritising the Backlog continuously.

Cycle time: A Kanban metric similar to Lead time. This refers to the time between a task being picked up and started, and its completion. In this way, an item’s Cycle time will always be shorter than its Lead time.

Daily standup: A Scrum meeting (sometimes known as the Daily Scrum) that is also used by teams working in other Agile frameworks. The Agile Development team and Product Owner meets each day, for a maximum of 15 minutes, and each Development team member provides a short progress update. Often, team members mention what they did the previous day, what they plan to do today, and any impediments/blockers they face - though this structure isn’t mandatory. The Scrum Master may attend this meeting as a facilitator, but does not provide an update themselves. Stakeholdersand others may also be invited as observers, but are discouraged from actively participating.

Decision Delays: This is a stance recommended for Agile teams: wait until the last responsible moment to make decisions. Once there’s just enough information, the team takes vague requirements and making them fine-grained and estimable.

Declaration of Interdependence: A set of modern management principles developed in 2005 by several of the authors of the Agile Manifesto, along with other experts. The declaration has the broad aim of being relevant to managers in different industries and disciplines beyond software development. Its six principles are:

We increase return on investment by — making continuous flow of value our focus.
We deliver reliable results by — engaging customers in frequent interactions and shared ownership.
We expect uncertainty and manage for it through — iterations, anticipation and adaptation.
We unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through — group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through — situationally specific strategies, processes and practices.

DEEP: A descriptive acronym for the quality of a product Backlog in Scrum that stands for: Detailed appropriately, Emergent, Estimated, and Prioritised.

Defects: Defects are inevitably encountered and created by the Agile team. The causes of defects come in two categories: Common causes and Special causes - basically, defects that might be expected, and defects that come from unique or unexpected events. An Agile team shouldn’t be afraid of making mistakes and causing defects, but they should have reliable processes to find, track and fix these defects.

Development Team: A Scrum role that can be summarised as the “product builders” - the people who do the work of producing the work described in the Backlog. In Scrum, the ideal size of a development team is 3-9 people. The team is not always solely made up of coders - ideally it would include engineers, designers, QA testers, content specialists - anyone who implements the work. In Scrum, a Product Owner may sometimes be a member of the Development team, a Scrum Master should never be a member of the Development team. Both roles have separate responsibilities.

Definition of Done: A working Definition of Done (often shortened to DoD) is a set of conditions which each work item or User Story must meet in order to be counted as ‘Done’. Defining done removes uncertainty, and forces developers, product owners, and team members to align on standards for completion. Example criteria are: if the code is reviewed, if supporting documentation is written, if accessibility standards are met, if specific Acceptance Criteria for that story are met, and if it’s been approved for release by the Product Owner. The DoD must be set and maintained by the Development Team. Not having a shared definition of done makes estimating User Stories harder. Without knowing the definition of done, it would be impossible for Stakeholders to know when an Agile project is finished.

Definition of Ready: This tool, similar to the Definition of Done, is a set of common standards that may be applied to a work item or User Story. It’s used at the point where a team considers picking up this work item - for example, when deciding whether or not to add the user story to a Sprint. Often, INVEST criteria are used for a Definition of Ready, but a team can create their own. Example criteria: ‘can this be tested?’ or ‘Do we know how to demo this?’.

Dot Voting/Dotmocracy: A common technique aimed at getting agreement within the Agile team, or the team and Stakeholders. A facilitated event in which the team has a set amount of dot stickers to their name. They are then asked to vote on certain options - and are free to use all their stickers on a single option, or to spread the stickers on various options depending on priority. Dotmocracy can be used in Retrospective, Sprint Review and Sprint Planning meetings, too.

Dreyfus Model: Based on an academic report from 1980, this model refers to skill acquisition. It can help explain the feelings teams new to Agile will experience. The five stages of the model are: Novice (needs instructions and a lot of management); Advanced beginner; Competent; Proficient; Expert (has attained skill mastery). A Self-Directed Team will have a lot of experts, and will only need occasional coaching and support from an Agile project manager or Scrum Master.

Drum Buffer Rope: A scheduling process closely associated with the Theory of Constraints and the need to limit Work in Progress in systems like Kanban. It uses the metaphor of a Scout troop on a hike - and needing to keep hiking at the same pace to stick together as a group. So here, the Drum is the constraint - the slowest Scout in the troop. The Buffer is the slack in the rope tying the Scouts together. The Rope itself ties the Scouts together and enforces the pace. Pulling on the rope to speed things up is the equivalent of adding too much work in progress: the buffer disappears but the slowest Scout doesn’t go any faster.

Dynamic Systems Development Method: Or, ‘DSDM’. An agile framework with a major focus on teams being on time and on budget. It has its origins in the Pareto principle, and is often used with traditional project management frameworks ITIL and PRINCE2. Its guiding principles - such as empowered teams, frequent deliveries and involving the end user - closely match those of other Agile frameworks. Roles on a DSDM team are: Project Manager, Business Sponsor, Business Visionary, Technical Coordinator, Business Analyst.

Elevator Statement: A technique where the team works on a short statement - short enough to be delivered in an elevator ride - describing the value their project brings to the user. It’s the overall vision of the project. In a more extreme version of this technique, the team is encouraged to cut this statement down to the length of a 140 character Tweet.

Emotional intelligence: An important characteristic of Agile team members, given that teams need to feel comfortable with sharing their feelings about their work, and their ways of working. A team member showing emotional intelligence will pick up on the feelings of their teammates and help change ways of working for the better as a result.

Empirical Process Control: A theory that is the basis of Scrum, a widely used Agile framework. It focuses on the three core principles of Inspection (reviewing things), Adaptation (changing things based on the review) and Transparency (being transparent about these changes, and other communications).

EMV: Or, Expected Monetary Value. This is a method of assigning a price tag to a risk associated with a project, often used as part of Risk analysis. It’s a decimal number which can be calculated by multiplying the probability of the risk occurring, with the impact of the risk if it occurred. So if a risk had a price tag of $100 and has a 25% chance of occurring, its EMV is $25.

Enterprise Scrum: A scaled Agile framework, similar to Spotify model, LeSSand SaFE. The framework includes multiple levels of planning and reviews. One distinctive feature about this framework is that the Backlog is known as a Value list, with each item measured against the Scrum values of commitment, courage, focus, openness and respect.

Epic: This is a “large value statement”, describing part or all of an Agile project or initiative. It’s a collection of several thematically-linked User Stories, and is a parent to them. Chunking stories into Epics helps an Agile team plan and prioritise their work.

Estimation: The process by which an Agile team establishes the size of the various User Stories on their Backlog. Techniques used for estimation include Planning Poker and Wide-band Delphi. An important feature of Agile estimation is that work items are estimated using Relative Sizing - this one is larger than that one - rather than in the predicted time the item would take to complete - hours/days. All estimation techniques are designed for speed, ease and accuracy. They can help with project planning, but should also encourage conversation within the team.

EVM: This stands for Earned Value Management. This metric, which has its background in US government project management in the 1960s, measures actual progress vs planned progress and is expressed as a percentage or decimal number. EVM depends on having a good baseline plan to start with, and may be used on an Agile project, provided that you’re careful about what you’re measuring. To get an EVM score, first attach price tags to all project activities over time, and roll them together to get a Budget at Completion (BAC). Then as the project proceeds, measure the Earned Value (EV), which is the budgeted cost of work that has been completed. If greater than 1 (eg, 1.04), a project’s EV signals that it is ahead, in that it’s delivered more value than expected at that point of time. If less than one (0.96, for example), the project is behind, in that it has delivered less value than was expected at that point in time. EVs can be measured against either schedule or costs.

Fast Failure: Fast failure may occur when a particular risk or threat is more impactful financially than the entire cost of the project.

Features: Sometimes, this term is used to describe a particular aspect of a product or service that an Agile team is responsible for. Specifically for project planning and requirements, it’s also used to refer to a group of User Stories that is itself below an Epic in the hierarchy. So, each (parent) Epic would have multiple (child) Features; each Feature would have multiple User Stories.

Feature Driven Development (FDD): An Agile methodology aimed at larger teams (30+ members). The FDD process that is best known is the concept of Sprint Zero, in which an overall model for a project is developed up front, and the various Features are roughly sequenced. To many, FDD is really a simplified way of running a Waterfall project in an Agile environment. Development in FDD is done by small, dynamically formed ‘Feature Teams’ who work on a particular feature, beginning to end.

Fibonacci Sequence: A series of numbers (1,2,3,5,8,13,21…) which describes a wide variety of natural phenomena. For Agile teams, it’s commonly used to apply Story Points to User Stories in Estimation techniques (such as Planning Poker).

Fishbone diagram: Fishbone diagrams, also known as Ishikawa diagrams, are used by Agile teams to identify potential factors behind an effect or Defect. In the diagram, the defect is at the head of the fish, with causes (personnel, measurements, etc) branching off from it like fish bones.

Five Whys: A technique to find the root cause of a process problem, or generally get to the bottom of an issue. The background of this technique comes from the manufacturing world, and was a way for workers to find Defects. In practice, it involves asking “why” five times. When applied to a risk event or process problem, it guides the conversation away from the most obvious reasons or causes, and encourages the team look deeper and find underlying dynamics or issues.

Gantt chart: A type of graph commonly used in traditional project management that shows the different stages of a project being delivered over time. Most Agile projects do not use Gantt charts, unless they are using a tailored method that needs that type of reporting. Instead, reporting is best served in a highly visual way that is easy to understand and does not fix time and scope - such as Roadmaps.

Generalised Specialists: People who are good at their job but can also do other things. For example, a designer who can code, or an engineer who’s a great QA. The more generalised specialists on a Development team, the better.

Gulf of Misunderstanding: AKA, the “Bermuda Triangle of Agile”. This is a term for when an Agile team and their Stakeholders are not seeing eye to eye. This leads to the danger that the team won’t deliver what’s needed by the users, and will fail to deliver value. Agile invites rapid pivoting, scope changes and deprioritises comprehensive documentation, meaning that the gulf of misunderstanding is a particular risk for such projects. Frequent checkins with Stakeholders are necessary for preventing the Gulf from opening up.

Ideal Time: Ideal time is basically a duration of time that something would take if you didn’t have any distractions at all, meaning that in a 40-hour work week, you didn’t do anything else except work on your project. Ideal time isn’t an effective way to plan. Agile recognises the inevitability of things going wrong, distractions and experiments; it rejects up-front deadlines based on ideal time.

Information radiator: A big visual chart placed in a prominent location. It conveys key information and shows the health of an Agile team. It is used to visualize the flow of work, shows where bottlenecks (or blockers) occur, and enables anyone to see what the team is working on at any time. Items like a Kanban board and a Burn down chart could be considered information radiators.

Intraspective: An ad hoc meeting, outside of scheduled per-sprint meetings like the Retrospective and Sprint Review, in which the Agile team considers something that’s not going as planned. It’s deliberately casual, and involves a discussion on reviewing team practices and Team norms. Such meetings may or may not result in specific decisions or actions - the important thing is open and honest communication and transparency - looking inwards. An intraspective allows the team to focus on the future, determine what could go wrong, and focus on the best ways to move forward.

INVEST: A model for writing User Storiesthat is also commonly used as a basis for an Agile team’s Definition of Ready. It can really help improve the quality of a team’s Backlog. It stands for: Independent, Negotiable, Valuable, Estimable, Small and Testable. Ideally, each User Stories should fulfil each of these characteristics.

IRR: Or, Internal Rate of Return. relies on the interest rate used to determine the value of future money. ‘Internal’ means no external influences, ‘rate’ means a percentage, return is ROI. So, for a project, the IRR is the rate at which the project revenues are equal to costs. The higher the IRR of the project, the better.

Iteration 0/Sprint Zero: A Sprintthat happens right at the beginning of a project. Tasks could include setting up the foundational elements before the first sprint, so the team can immediately start building value. Setting up workspaces. Writing User Stories. Establishing the team’s Elevator Statement. This sprint can be as long or as short as you need. Sprint Zero is a concept popularised by the Feature-Driven Development framework.

Iteration H: A Sprint with the purpose of hardening or finalising your release contents to ensure your release is ready to move to production. It usually has the same time box as your development iterations. Common tasks include doing extra testing, finalise documentation, stabilise things before release. H sprints are far from common in Agile teams - and could even work against the general principle of releasing frequently.

ITIL: Stands for ‘Information Technology Infrastructure Library’, developed in the UK in the 1980s. A traditional process, whereby a team first creates some software, then supports the results by using a set of ITIL principles. It’s therefore often used by support teams/IT services, to help them maintain and troubleshoot in-market products.

Kaizen: A term often used in Agile to mean improving the quality of the work by making small adjustments over time, also known as ‘continuous improvement’. A Retrospective meeting is a common occasion for agreeing on such adjustments.

Kano Analysis: Often used in Agile by the Product Owner as a backlog prioritisation technique. The PO assesses a set of User Stories, in a meeting with stakeholders, and then categorises these stories in four buckets: 1) Exciters (features that get the customers excited), 2) Satisfiers (basic, to be expected features), 3) Dissatisfiers (features that will cause customer to dislike the product if they’re not there), 4) Indifferent features (customers don’t care about them). It’s an effective technique for smaller groups of stakeholders.

Kanban: A Lean scheduling system that has its basis in Japanese manufacturing practices - specifically those of the Toyota car plant starting from the 1940s. These days, it is a commonly-used lightweight Agile framework. Kanban was originally developed to reduce waste and enable just-in-time production. An important focus of Kanban is to limit Work in Progress and tighten Lead time. Sometimes, people use ‘Kanban’ to refer to a Kanban board. The five core practices of Kanban are Define and Visualize the workflow, Limit WIP, Measure and Manage Flow, Make Process Policies Explicit, Use Models to Suggest Improvement.

Kanban board: Roughly translated, the word Kanban means a “visual card”; for Agile teams, Kanban is associated with a board containing different columns for each status (such as to do, in progress, done). Tasks/work items are cards on the board, and are “pulled” through by members of the Development team. Boards are effective Information radiators and are often the focus of a team’s Daily Standupmeeting.

Key performance indicators (KPIs): Ways that most Agile teams track performance. Every team will have their own KPIs, and they are often shaped and guided by the broader organisation. They’re goals and objectives, often written using the SMART framework. KPIs tend to be based on both tangible results - like time spent or money made - and intangible items - like how a team works together.

Lead time: A metric particularly associated with the Kanban framework and closely related to Cycle time. Like many other Kanban features, this term has its origins in Lean manufacturing. An item’s lead time is the time between a task being recorded up to the time it was completed - start to finish. For example, the time between a User Storybeing added to the Backlog, and it meeting the team’s Definition of Done. Kanban teams keep a close eye on average lead time, and aim to make it as short as possible.

Lean: A management style that, like Kanban has its roots in the Toyota production system of the 1940s, and is an important influence on Agile. The link between Lean and Agile was made in a popular book by Mary and Tom Poppendieck in 2003. These are a set of principles aimed at eliminating waste from a project. Waste is defined as any activity that does not create value for end users. It’s also the basis of Lean Six Sigma - a business approach to ensure quality through applying Lean Principles. Lean particularly focuses on getting rid of waste in a system, such as overproduction, waiting time or Defects.

Lean Principles: These are: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower teams, Build quality in, See the whole.

Large-Scale Scrum (LeSS): An enterprise agile framework for an org that has 8+ Scrum teams. Characteristics of this framework include a single Product Owner across teams that sets an overall direction, working with one or more Scrum Masters to overcome larger scale inefficiencies. Unlike other scaled Agile frameworks such as SAFe, it’s aimed only at Scrum teams and doesn’t include other frameworks like XP or Kanban. There are two separate sprint planning meetings (one for what the team will deliver, and the other on how they’ll deliver) and three different backlog refinement sessions (one for all teams, one for each team, one for combinations of multiple teams working in the same area). And two Retrospective meetings (overall, and per team).

Larman’s Laws of Organisational Behaviour: These are a set of observations that illuminate the struggle many organisations have in adopting Agile ways of working. The ‘Laws’ include: ‘Organisations are implicitly optimised to avoid changing the status quo’, and that ‘Culture follows structure’ - if you change how people work, the way they think about the work will change too. The inventor of the laws is also one of the creators of the LeSS framework.

Likely costs remaining: A metric sometimes used by Agile project managers. This is a number calculated by multiplying the salary burn rate for team members by the remaining time needed to complete a project.

Mirroring: An important aspect of effective communication within a team, part of Adaptive leadership. Teams tailor communicate with someone, to match them. Using the same phrases, matching body language, and so on.

MMF: Minimum Marketable Feature - a feature by which the product meets essential early demand, but is not the whole product. It’s the smallest set of functionality in a product that must be provided for a customer to recognize any value.An MMF gives the team an early sense of ROI, either through the sales or stakeholder goodwill which results from it.

Monopoly money: A prioritisation technique used as an alternative to Dot voting or MoSCoW. Used in a facilitated event or meeting, often with the Agile team and Stakeholders. Individuals or groups are given a set amount of money to “spend” on a list of options - for example, future features for a product - and can allocate their funds to one or more of these options as they wish. Crucially, each of these options/User Stories/Features have been assigned a price. Each participant is generally given enough money to cover 50% of the cost of everything listed. Like in Monopoly, there’s a “banker” who tracks purchases and gives change. Everyone is empowered to buy and trade. At the end, the options with the most amount of money may be seen as more important or higher priority, and vice versa. This can help clarify things for both the team and Stakeholders, and narrow the Gulf of misunderstanding.

MoSCoW: Often used in Agile by the Product Owner as a Backlog prioritisation technique - though it can be used in meetings with Stakeholders to prioritise any list of options. For backlog prioritisation specifically, the Product Owner assesses a set of User Stories, in a meeting with stakeholders, and then categorises these stories into Must have, Should have, Could have, and Would like to have - but not now - features. MoSCoW is an easy-to-use technique as it helps focus on essential vs non-essential features.

Muda, Mura, Muri: A Japanese term that’s an important tenet of Leanthinking. These are three ways in which resources can be allocated inefficiently. Each should be eliminated as much as possible. Muda is ‘waste’ - work that absorbs resources but adds no value. Mura is ‘unevenness’ - work that does not have a constant or regular flow. Muri is ‘unreasonable’, as in an unreasonable burden on workers or systems.

MVP: Or, Minimum Viable Product. This is a mini-version of your product, developed and released as fast as possible, with the aim of getting quick user feedback. It can be working software or a prototype. Agile methodology focuses on the fastest time to market - it accomplishes this by focusing on the minimal amount of of features needed to solve a problem for the marketplace.

NPV: NPV stands for ‘Net Present Value’. It’s a metric that describes the difference between the cash value of a project at the present time, and how much money we expect to get from the project in future. NPV is calculated by using a project’s Payback Period and IRR. It’s the gold standard project metric when a project is chartered as it provides the best overall determination of fiscal health when selecting a project. NPV is a decimal value. If it’s above 0, your project is profitable - future gains are expected to outweigh your present investment. If it’s below 0, it is not profitable. Therefore, the higher the NPV for a project, the better.

Osmotic communication: When team members gain valuable information by overhearing other conversations. An important benefit of Co-location.

Pair Programming: An XPpractice that is used more generally by many Agile teams. One member of the Development team writes code while another watches and determines if it looks good to them. Then they switch roles from time to time. This helps keep everyone accountable for the work they produce, and the extra pair of eyes means code quality should improve.

Pareto principle: AKA, the 80/20 rule. It originated with the Italian academic Vilfredo Pareto in the 1900s. He observed, when studying wealth distribution, that 80% of the output came from 20% of the people. For Agile teams, it may be observed that 20% of a product’s features produce 80% of the product’s overall impact. Or contribute to 80% of the Defects!

Payback Period: Part of the calculation of NPV and by extension ROI. The time it will take for an organisation to recoup the money spent on a project and begin generating a profit. It can be a forecast future date. The lowest payback period is always the best - because it means the project is taking less time to reach profitability.

Penny Game: A collaboration game played by Agile teams. In the game, the team is assigned roles and works together to flip over pennies. The goal of the game is to encourage self-organization and demonstrate how a team is less productive when processing large work loads. Flipping the same number of pennies in smaller batches is faster and more efficient. The game illustrates the desirability of limiting Work in Progress.

Personas: A fictional person with unique traits, that are created and used by an Agile team as a way to understand their customers. The team generally uses several personas, each representing a group of users. They help teams focus on how various user goals look different - from each persona’s point of view. Personas can be prominently displayed in the team’s workspace as a reminder of who they’re working for.

Planning Poker: A widely-used Estimation technique, which came to popularity in the early 2000s along with the Scrum framework. It’s based on Wideband Delphi. It relies on anonymous, simultaneous voting by the Development team on how many Story Points a particular User Story should be assigned. Disagreement in these estimates is to be encouraged, as it stimulates useful conversation which clears up requirements and issues around work items. The Scrum Master may facilitate pokering, and the Product Owner is on hand to answer questions - but neither of these participate in the pokering itself. Ideally, planning poker leads to consensus on what it will take to deliver the story.

Poka Yoka: A continuous improvement concept applied to an Agile team’s ways of working. A Japanese term that means “mistake-proofing” - or specifically avoid (yokeru) mistakes (poka). It works by preventing, correcting, or drawing attention to errors or Defects as they occur.

Postmortem: A meeting held with the Agile team at the end of a project, in which the team reflects on what happened during the project. Commonly, there is a focus on what went wrong with the project, and the discussion is focused on ways of avoiding such things happening in future. This meeting is ad hoc and called only when the team decides it is needed.

Premortem: An ad hoc “what could go wrong” meeting, which differs from a Postmortem meeting in that it occurs towards the beginning of a project. Aimed at involving the Agile team in discussing all of the ways in which a to-do or in-progress project could hypothetically fail - a process known as ‘remember the future’. This meeting can be used as part of Risk analysis, and promotes open conversation and transparency.

PRINCE2: Stands for ‘Projects IN Controlled Environments’. A traditional project management framework developed by the UK government that’s applied by businesses beyond the world of software development. The principles and themes of PRINCE2 often match Agile frameworks, even though it predates the Agile Manifesto.

Process tailoring: An Agile team may take elements from one or more frameworks - both traditional and Agile - in order to find the best process for their team. An important stage following the mastery of a certain framework or process. Closely allied with the concepts of the Dreyfus Model and Shu Ha Ri. It isn’t recommended to try to create a hybrid approach until all best practices are well understood and have been used. This doesn’t mean that you couldn’t incorporate stand-up meetings on your next Waterfall project. It’s just not recommended to combine full frameworks until everything is well accepted and understood.

Procurement: An especially difficult area for an organisation to adopt Agile practices - and many simply don’t use Agile procurement as a result. Contracts are commonly handled by the legal team, and it is rare that an Agile project manager would be involved in such negotiations. This means teams tend to work under traditional fixed-price agreements for the goods and services they use, a poor fit for the Agile principles of flexible scope and rapid changes. That said, Fix and Switch contracts (fixed price/scope/time, but vague enough that it can be altered to meet customer needs) have been used by some organisations as a better fit for Agile projects.

Product Owner: A member of the Scrumteam whose main job is to maximise the value of the product. They are often a representative for the Project Sponsor. Many feel this is the most important role on the team. The Product Owner owns the Backlog and is responsible for grooming the backlog. Often, they are a customer representative that owns the product.

Process Efficiency: A technique that encourages Lean thinking. Process efficiency is calculated by taking the time wasted and dividing it by the total time spent: so for example if there was 15 minutes of extra waiting around on top of a 60 minute meeting, the Process Efficiency calculation would be 15 / 75 = 0.20, or 20%.

Product/Project Vision: You need a shared vision, or the team will have a lot more misunderstandings. The Product Owner communicates that vision and makes sure the team understands it. A vision may include the product’s target group, goals, needs, the value it brings, along with any key features. It aims to consider the problem the product solves, as well as the opportunities the solution brings. In Agile teams, a product vision is often synonymous with the Elevator Statement.

Purpose Alignment Model: A chart used by Agile teams, providing a simple way to determine what activities to concentrate on, and how to deliver them. The chart has four quadrants (Partners, Who cares? Parity, Differentiated), which are arranged along two axes: Market differentiator and Mission critical. In a workshop, the team and key Stakeholders plot various factors on the chart. Ideally, it helps align the team on a particular strategy for the project overall. It can be helpful in Chartering or putting together an Elevator Statement.

Product Sponsor: A Stakeholderwho is a major decision maker in the organisation. While they are not on the core Agile team, they should have an influence, participate in workshops and Sprint Review meetings.

Progressive elaboration: The process of incorporating new information into an Agile team’s plans and reprioritising the backlogaccordingly.

Prune the product tree: A collaboration game that helps an Agile team prioritise feature requests, and determine which User Stories should be written or worked on. The team works together on a board with a picture of a tree, with lots of branches spreading out from the trunk. Features are put on different branches: the trunk represents the product’s MVP, while features placed at the extremes of the branches represent things to deliver far in the future, long after the MVP.

Rate of progress: A metric used in traditional and Agile project management. In Agile, it’s the total number of stories being completed per iteration. Related to similar metrics that measure progress, such as Lead timeand Velocity.

Refactoring: An important set of recurring tasks for the Development team, involving tidying up code such that it runs in the most efficient way possible. Such changes might not be easily visible to Stakeholders, but must be planned for and accommodated by the team. Refactoring often has the aim of eliminating Technical debt built up from previous work.

Relative sizing: The foundation of all agile estimation techniques, such as Planning Poker. At its core, it’s the Agile team looking at multiple User Stories and deciding which seem ‘bigger’ in terms of their complexity, and which seem ‘smaller’ - rather than estimating how many hours/days something would take to complete. Such comparisons help make more accurate estimates.

Remaining work: Everything left on the Backlog that must be done in order for the project to be completed.

Retrospective: A Scrum meeting that is often used by other Agile teams, too. Held at the end of each iteration/sprint. In each retrospective meeting, the Scrum Master (or whoever is facilitating the meeting) asks: what went well in the last sprint? what could be improved? what can we change going forward? Any agreed-on actions are added to the next Sprint Backlog (in Scrum) or are otherwise recorded and checked back on at the next retrospective meeting - perhaps in a Starfish diagram. You need to make sure that any actions are realistic, don’t depend on others outside of the team, and overall add value to the project.

Risk-based spike: Similar to an Architectural spike in that it represents time out taken by the Agile team to investigate something. It may be a task within a sprint/iteration, or might itself count for a short iteration between more ‘normal’ sprints. The purpose of a risk-based spike is to test an unfamiliar or new technology and determine the risks that adopting this technology would lead to.

Risk adjusted backlog: An Agile team may use Risk analysis and EMV to apply a “price tag” to the risks represented by each User Story, bug and task in their Backlog. This information may then be used for the Product Owner in their Backlog prioritisation.

Risk analysis: Can be used by an Agile team to identify threats. Approaches vary in weight, but often include a Brainstorming session that focuses on everything that could go wrong and negatively impact the project. Threats are then quantified and logged; they are generally listed based on how likely the risk is to occur, potential losses and recovery time. The session can also help the team build out a Risk adjusted backlog.

Risk burn down charts: A line chart that shows the project’s risk exposure over time. Just like a Burn down chart it’s a line graph that should hopefully trend downwards as risks are mitigated. For the inputs to this chart, the team should assess their Risk adjusted backlog and EMV calculations, and update the probability of risks occurring at that particular point in time. The Sprint Review meeting is a good opportunity to showcase such a chart, and Sprint Planningis a good time to update it.

Roadmap: A visual overview of short/long-term priorities for an Agile team. Commonly, it showcases and categorises a product’s overall requirements. Think of it like a “weather forecast”: it suggests what might happen in future, and you can be more confident about what will happen tomorrow than what will happen next month.

ROI: A ratio of the benefits received from the project vs the money invested in the project. For example, an ROI of 3:1 has a payback that is three times as high as the costs. A higher project ROI is always better.

Rolling Wave Planning: This is an Agile planning technique that involves revisiting and adapting planning throughout a project - riding waves of information, which keep on coming in to shore, and adjusting plans, rather than getting all the planning done up front. You could use an iteration/release as a cue to revisit plans. As an Agile team, you’re always looking for the “last responsible moment” to make or change plans.

Sailboat: A collaboration game that can be used in a Retrospective meeting. The team works on a board with a picture of a sailboat, and assign different events or effects in one of four categories: Rocks (risks that might sink the boat); Anchors (delaying issues); Wind (things that push the boat forward); Sun (things that make the team feel good).

Satir Model: A way of thinking about change in organisations popularised by Virginia Satir, a family counsellor. The model holds that when a foreign element is introduced into the status quo, the organisation goes through stages or resistance, chaos and then finally integration, and the adoption of a new status quo. This model accurately describes many organisations’ experiences with Agile transformations.

Scaled Agile Framework (SAFe): A way of applying an agile framework in larger teams and organisations. Similar to Crystal methods, there are several configurations of SAFe, depending on team size, from Essential SAFe to Full SAFe (thousands of people). One particular characteristic of SAFe is a specific type of implementation Roadmap that can highlight the planned future work of multiple teams. There are also shared meetings/events and, like the Spotify model, communities of practice for people in different teams with similar skills.

Scrum: The most commonly used Agile framework for teams. Scrum has its foundations in Empirical Process Control and its three “pillars”: transparency, inspection and adaptation. Scrum popularised the concept of the Sprint, an increment, commonly lasting for two weeks, in which the team commits to getting a set of User Stories done. Scrum is an out of the box methodology with fixed roles and repeatable activities, including the Daily Standup (which in Scrum is called the ‘Daily Scrum’), the Retrospective, Sprint Review and Sprint Planning. Scrum comes with a set of documents, which it also calls ‘artefacts’: the Product Backlog, the sprint backlog (work selected from the product backlog for the sprint) and the product increment (what’s actually built each sprint). Scrum has a lot of structure around it so teams can follow a pre-defined process. Scrum has five values: commitment, focus, openness, respect and courage.

Scrum Master: The best description of this role is Servant leader. A good Scrum Master fills in the gaps in a team - booking the meeting rooms, doing admin work, chasing up Stakeholders and keeping the team on track to achieve their goals. A Scrum Master is not a manager: they’re a trainer, a coach, an administrator. They are a “bulldozer” (through obstacles) and a “shield” (protecting from interference). Any authority a Scrum Master has comes with their knowledge of the Scrum framework and Agile principles and practices more generally.

Scrum of Scrums: A regular meeting (up to 3 times a week) in which Scrum Masters and other interested parties meet to divide up work and identify dependencies between Scrum teams. The meeting should improve communications, limit blockers and encourage Scrum best practices across teams.

ScrumBan: A hybrid approach that incorporates aspects of both Scrum and Kanban as needed, and it was originally created as a way to transition from Scrum to Kanban.

Seiri, Seiso, Seiton, Seiketsu, Shitsuke - Five S: A methodology, based on Lean principles, that helps a team organise their workspace to enhance productivity. The words mean ‘Sort, Straighten, Sweep, Standardise, Sustain’.

Self-Directed Teams: A mark of an effective Agile team. A self-directed team makes their own decisions on their processes, prioritisation and ways of working. In this happy scenario, an Agile project manager or Scrum Master is there to provide occasional coaching and help with admin tasks. They’re not needed for anything more!

Seven Wastes: A way of applying Lean Principles - the first of which is ‘eliminate waste’ to software development. The seven types of waste are: partially done work, extra features, relearning, handoffs, delays, task switching, Defects.

Servant leadership: The most important characteristic of a Scrum Master, and by extension an Agile project manager. Somebody who serves the team and leads by example by coaching the team on Agile principles. A servant leader must use Active listeningto identify and solve problems in a team’s ways of working.

Shewhart cycle: A way of encouraging continuous improvement in ways of working that can be followed by Agile teams. The cycle is plan-do-check-act.

Shu Ha Ri: A Japanese term referring to the mastery of skills, based on Aikido martial arts. Shu means ‘to protect or obey’; Ha means ‘to detach’; Ri means ‘to leave’. It chimes with the Agile way of thinking, in that you start off by following an unfamiliar framework or process closely to get the basics right, then as you master it, you feel increasingly confident in branching out and breaking rules for the good of the outcome.

SMART: A framework for writing KPIs. It’s an acronym, standing for Specific, Measurable, Achievable, Realistic and Time-bound.

SPECTRUM: A prompt list used by the facilitator of a Brainstorming session, used as part of Risk analysis. Prompt lists are a way to focus the conversation and label identified risks. Stands for: Sociocultural, Political, Economic, Competitive, Technology, Regulatory, Uncertainty, Risk.

Spotify model: A system of scaled Agile, like SAFe and LeSS. Teams are organised into Squads, and work autonomously. Cross-squad standards are maintained through Tribes and Guilds, for example a team of designers or a team of product managers who themselves work on different squads. It’s aimed to be a looser and more process-light framework with no mandatory meetings, like in SAFe. Unlike LeSS, individual squads can choose to work in Scrum, Kanban, XP or any other framework.

Sprint: This term is closely associated with the Scrum framework. It’s used interchangeably with the term ‘iteration’ - though if it’s a Scrum team, they’ll use ‘sprint’. It’s a period of time, less than a month and commonly two weeks, in which an Agile team aims to achieve a goal by completing various work items. Teams commit to this goal and the work items (usually a collection of User Stories) in a Sprint Planning meeting at the start of each sprint. Each day of the sprint has a Daily Standup meeting; they hold a Sprint Review towards the end of the sprint; the sprint ends with a Retrospective meeting. Sprint scope should only change with the agreement of the Product Owner and is discouraged. Very occasionally - usually only when some new information has made the sprint goal redundant - the sprint may be cancelled. Only the Product Owner can make that decision.

Sprint Planning: A Scrum meeting that happens at the beginning of each Sprint. In this meeting, the Product Owner brings a priority sorted product Backlog to the team, and they discuss how they can deliver the most value in next Sprint. They may discuss or Estimate high priority User Stories, bugs and other work items, and see what will fit in the Sprint. Often, the team’s predicted Velocity will be an important guide for this process. The agreed-on work items are then added to the Sprint backlog, and the team agrees on a high-level goal for the next sprint. At the end of the meeting, the new sprint has started.

Sprint Review: A meeting in Scrum that can also be adapted by other Agile teams - it can be called ‘Steer Co’, ‘Checkin’ or similar. During the meeting, the Product Owner shows stakeholders the User Stories that were worked on in the past sprint, and mentions those accepted as meeting the team’s Definition of Doneand those that were not accepted. Often, the Development Team demos the working product to illustrate this. Stakeholders provide feedback, which is recorded and incorporated into the Backlog, whether as an update to existing User Stories, or the basis for new ones. Showing your work in progress is essential Agile practice. It’s the first thing in a sequence of activities that end the sprint, and is followed by a Retrospective.

Stakeholders: They’re either people you work with, or end users. Agile doesn’t advocate controlling stakeholders, rather an Agile team engages or collaborates with them to unlock value. An Agile team should aim for frequent but brief stakeholder involvement. The Product Owner helps express the Stakeholders’ ideas as User Stories. Stakeholders may attend the Daily Standup as observers only, and actively participate in the Sprint Review.

Starfish diagrams: An Information Radiator that can be used to capture actions agreed on at a Retrospective meeting. They are often kept on the wall next to the task board. It can be updated during the sprint as any actions are completed. The diagram features a drawing of a starfish, with each segment labelled with one of the following: Keep Doing, Start Doing, Stop Doing, Less of, More of. Sometimes updates to the diagram only happen during the meeting - for example, the facilitator displays the diagram showing the actions agreed on last time at the beginning of the next Retrospective.

Story Points: A unit of Estimation applied to User Stories. Generally, these follow the Fibonacci Sequence. The typical number of Story Points delivered for each Sprint is the team’s Velocity - an important performance metric in Scrum and other Agile frameworks.

Swarming: Swarming is a behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items.

SWOT: A framework for a Brainstorming session, commonly used for Risk analysis. An acronym for Strengths, Weaknesses, Opportunities and Threats, each of which has its own corner of a standard SWOT diagram.

Tacit knowledge: Information that is more difficult to explain or to put into writing, and may require some form of documentation. For Agile teams, tacit knowledge can’t be gained through Osmotic communication, it requires closer attention.

Takt Time: A German phrase, meaning ‘pace’ or ‘rhythm’. In Agile team terms, it’s the rate at which the team needs to work to keep up with customer demands.

Team Norms: These are ground rules created by an Agile team to guide the project and how members interact, especially during the initial Norming stage of Tuckman’s Ladder. You should aim to create norms at a workshop. Review team norms regularly but occasionally. Examples of team norms can be general - for example ‘silence means consent’ (if you disagree with a decision, speak out, but if you don’t, you’re committed to the decision). Or can be specific, such as agreeing to have ‘no meetings before 12pm on Wednesdays’.

Technical Debt: This happens when a member of the Development team implements something quickly that’s not put together in the most efficient way. For example, a piece of code that passes tests, meets Acceptance Criteria and the team’s Definition of Done, that is accepted by the Product Owner and is released, and that meets the general Agile principle of delivering working software frequently… but stores up trouble in the future due to its inefficiency. Refactoring such code, and eliminating the technical debt, is an important set of tasks for the team that must be accommodated over time.

Test-Driven Development (TDD): An XP practice in which for a piece of development work, the tests are written before the code. This - in theory - alleviates common issues from the traditional ‘build first, test later’ approach: Defects, scope creep and replanning. Ideally, TDD forces the Development team to be outcome focussed rather than code focussed.

Theme: The overall theme of your project, which helps drive the vision and goal(s) shared by the team. If requirements in an Agile project were represented in a hierarchy, this is the top level, above Epic. So, a collection of thematically-linked Epics, each of which in turn have their own Featuresand User Stories.

Theory of Constraints: All projects have the Triple Constraints of Scope, Cost and Time. Constraints are often called bottlenecks in production systems. Once the bottlenecks are removed, flow improves. The Theory of Constraints holds that a team should analyse if any constraint in particular is causing a large number of bottlenecks, and focus attention on improving that constraint in order to improve the team’s processes overall.

Throughput: A Kanban metric that refers to the average amount of time that it takes the team to complete a work item, within a specific time frame. For example, how long it took a typical User Story to be completed last month. It’s a useful metric to measure as an alternative to Velocity for Kanban teams.

Timeboxing: A concept particularly prominent in the Scrum framework. It means the maximum time that should be spent on something. The core Scrum meetings (Daily Standup, Sprint Review, Sprint Planning, Retrospective) are all time boxed, as is the Sprint itself. Commonly, Architectural Spikes and Risk-based spikes are time boxed, too.

Triangulation: An Estimationtechnique in which a team compares one User Story with a couple of others to get a better estimate of its complexity.

Triple Constraints: Projects aim to strike a balance between the competing constraints of Scope, Cost and Time: these three are balanced to maintain the quality of what’s being built. Waterfall and Agile projects deal with these triple constraints differently. In Waterfall, Scope is fixed, with Time and Cost working around that constraint. For Agile, it’s the opposite: Time and Cost are fixed, Scope can change.

Triple Nickels: A technique used in a Retrospective meeting. To play, form small groups. In the groups, each person has five minutes to brainstorm and write down ideas individually. At the end of five minutes, each person passes the paper to the person on his or her right. That person has five minutes to write down ideas that build on the ideas already written on the paper. Repeat until the paper returns to the original writer.

Tuckman’s Ladder: This is a way of describing the various stages of team dynamics throughout a project, and how this team may be managed. This theory describes the stages through which a team progresses towards optimal productivity. New teams go from Forming (team is set up, manager coordinates) to Storming (team is in conflict, manager coaches) to Norming (team comes together, manager empowers) to Performing (team is motivated and successful, manager facilitates). Self-Directed Teams are at the Performing stage of the ladder.

User Stories: These are the component parts of an Agile team’s Backlog. User stories are the Agile alternative to the traditional list of requirements - and should be easier to understand if written well. They are short statements that describe a user benefit, often in the format “As a ____, I want ____, So that ___.” User stories aren’t requirements, they’re placeholders for future conversations. They help the team ask the right questions. User stories should contain a value statement, and be from the perspective of a user. Your team will get better at writing good user stories (with a simple value statement) over time. Sometimes, when a User Story is picked up for a Sprint, the Development team will break the story up into various sub-tasks, or add implementation details or Acceptance Criteria.

User story map: This is a graphical representation of multiple User Stories, for example the stories that make up a product, Epic or Theme. Sometimes people call it a ‘walking skeleton’ as it’s a bare bones view of a big piece of work involving lots of people. The map is often put together in workshop held early in the project and involving up to five engaged team members (more people would compromise the dialogue). In the graph, stories are arranged to match the way the user uses the product. Often, the team uses Brainstorming to create Personas and User Stories during the workshop. When built, the map helps the team see how the stories relate to each other. It can be used to determine the MVP.

Value stream mapping: These are diagrams, boards or images designed to show the value stream of the whole project and/or team processes visually from start to finish, and identify which bits add value, and which don’t. Value stream mapping allows the team to focus on the current state of things, and map out future improvements. They therefore encourage Lean thinking and improve Cycle time.

Variance and trend analysis: Variance analysis is a quantitative review of the differences between what we thought would happen versus what actually happened. While trend analysis is a quantitive review of what happens over a period of time. In most cases, variance and trends go hand in hand and are reported at the same time for the same metrics.

Vertical slicing: In which a product is built to function as small sections of incremental value, delivered sequentially. Contrasted to Horizontal Slicing, where different “layers” are the product must be built before the whole thing is delivered. Vertical slicing allows for the earliest possible delivery of an MVP.

Velocity: The typical number of Story Points delivered by a team, per Sprint. An important metric for Scrum. For velocity, long term, the team is aiming for consistency rather than an increase. A team tends to have a volatile (but rising) velocity across early sprints, before velocity plateaus.

Waterfall: A catch all term for traditional projects, in which the guidelines are strict, scope is defined up front, changes aren’t welcomed, and everything proceeds in pre-defined stages from beginning to end. It has its basis in a chart produced for a 1970s academic paper (which doesn’t use the word “waterfall”), and is often used as a straw man argument for “the bad old way of doing things” by Agile practitioners. Agile teams do pretty much the same work as in Waterfall, but you’re doing it in a lot more phases - analysing, developing and testing at the same time.

Wideband Delphi: The guiding concept behind Planning Poker and Estimation. This is a forecasting technique developed by the Rand Corporation in the 1950s, aimed at creating group consensus rather than ‘groupthink’. It requires estimates to be totally anonymous, meaning strong personalities in the group don’t have an outsize influence, and for the team to discuss matters to reach a consensus.

Wireframes: Simple visual mockups that show a product from a user’s point of view. For example, for a web app, a wireframe would show the user’s flow between screens. Wireframes are created by the Agile team and often shared with Stakeholders as a way of avoiding the Gulf of misunderstanding around requirements.

Work in progress (WIP): An important metric for Kanban teams. WIP is the amount of tasks/work/User Stories that are being worked on by the team at a particular point in time. Commonly, limiting WIP improves team processes and morale, and limits bottlenecks. Limits should therefore be strictly enforced. As the team becomes accustomed to the process and metrics are gathered, adjust the WIP limit to increase efficiency.

XP: Or, Extreme Programming. A commonly-used Agile framework for small teams (though not so common as Scrum). It was originally developed in the 1990s by some of the founders of the Agile Manifesto. Unlike Scrum, XP is explicitly for software development teams and can’t be applied to other types of work. It’s well known for practices such as Pair Programming, Refactoring, Continuous Integrationand Test-Driven Development, and is responsible for popularising these terms. The core values of XP are: simplicity, communication, feedback, courage and respect. XP roles map well to Scrum roles: there’s a coach (Scrum Master), customer (Product Owner), programmers and testers (Development team).