Agile Glossary

Glossary Image

With every major change to development practices there comes a whole new lexicon to absorb and understand. This glossary provides a central definition resource for getting to grips with Agile terminology.

A

Acceptance Test: a formal description of the behaviour of a software product, usually given as an example or usage scenario. Often acceptance tests are used as the main form of functional specification or the sole expression of business requirements.

Actionable, Specific, and Kind (ASK): feedback when pairing should follow the ASK principle of being Actionable. Specific and Kind.

Adaptive Software Development (ASD): a deprecated lightweight software development process that preceded Agile. ASD uses repeating speculate, collaborate and learn cycles to continuously adapt the process to the work being performed. ASD is iterative and time-boxed, mission focused, risk driven and change tolerant.

ADKAR: a goal-oriented change management model to guide individual and organizational change. ADKAR is an acronym representing the five milestones that must be achieved for a change to be successful –

  • Awareness of the need for change.
  • Desire to participate and support the change.
  • Knowledge on how to change.
  • Ability to implement required skills and behaviours.
  • Reinforcement to sustain the change.

Affinity Wall: used to organise and categorise information into logical groups. Following brainstorming the team organises Post-its into related themes and then titles each group. This method allows visual clarification of problems and identification of potential solutions.

Agile: a philosophy in which requirements and solutions evolve iteratively and incrementally through collaboration between self-organising and cross-functional teams. Agile promotes adaptive planning, continuous improvement and a focus on quality to reduce risk and achieve the highest value outcomes.

Agile Modelling (AM): a methodology for modelling and documenting software systems as introduced in 2000 by Scott Ambler. Initially named Extreme Modelling (XM) the methodology was renamed and published as Agile Modelling in 2002. AM provides a collection of values and principles to be used for modeling on an Agile development project.

AgilePM: Project management approach to Agile based on DSDM.

Agile Release Train (ART): a pre-planned regular schedule of releases to deliver functionality and updates within the Scaled Agile Framework. In SAFe-speak this is the primary value delivery construct organised around the enterprise’s value streams providing program increments (PIs) to the end user.

Agile Unified Process (AUP): an application development process adapted by Scott Ambler for Agile projects from the Rational Unified Process. AUP includes test-driven development, Agile modelling. Agile change management, and database refactoring. In 2012 AUP was superseded by Discipline Agile Delivery (DAD).

Alternate Release Burndown Chart: a graph showing the quantity of work remaining for a release (vertical axis) against the elapsed project time (horizontal axis). This chart also shows work added or removed from the backlog plus prediction lines based on the team velocity and work-add rate.

Andon (Japanese: Visual Indicator): a display, siren or other indicator to communicate information and encourage immediate resolution to problems. A live build and test dashboard on a wall-mounted monitor is a good example.ATDD (Acceptance Test-Driven Development): the practice of test-first development in which automated acceptance tests are written in advance of implementing the corresponding functionality. Ideally the product owner, customer or domain expert are able to write acceptance tests to express their desired functionality.

Automated Build: the process of generating a deployable product from its original sources without any human intervention. An automated build can be performed at any point with no further inputs other than the source code repository. Producing an installable version of the product is the most basic process in automation.

B

Backlog: an ordered list of the features or tasks to be developed for a product. See Product Backlog and Sprint Backlog.

Backlog Grooming: Now widely accepted as illegal, see Backlog Refinement.

Backlog Refinement: the practice of meeting regularly to refine the product backlog. This can involve re-ordering or removing backlog items, creating new ones or rewriting, re-estimating and splitting existing items. Refinement meetings ensure that the product backlog is kept current and has sufficient work for the team at the right granularity for the next few sprints.

Basic Unified Process (BUP): A cut-down version of the Rational Unified Process (RUP) optimized for small projects (3-6 people for 3-6 months). BUP was given freely into the open source framework OpenUP in 2005 and was developed further within that project.

BDD (Behaviour Driven Development): an extension of TDD and ATDD to describe the desired functional behaviour of new features in the form of tests written in a domain-specific scripting language (such as RSpec).

Before Product Market Fit (BPMF): seeking a Product Market Fit. “When you are BPMF, focus obsessively on getting to product/market fit. Do whatever is required to get to product/market fit. Including changing out people, rewriting your product, moving into a different market, telling customers no when you don’t want to, telling customers yes when you don’t want to, raising that fourth round of highly dilutive venture capital — whatever is required” (Mark Andreessen).

Beyond Budgeting: a leadership philosophy utilising an alternate approach to budgeting using a rolling budget, balanced scorecard, external benchmarks, managing future results, allowing operational managers to react to the environment and encouraging a culture of innovation.

BHAG (Big Hairy Audacious Goal): A long-term goal that changes the very nature of a business’ existence. BHAGs change the way that a business runs, and are bigger and bolder than regular long-term goals. They typically take ten years and over to achieve and are created with the following steps –

  1. Conceptualise it.
  2. Test it.
  3. Commit to it.

Big Visible Charts: See Information Radiators.

Build-Measure-Learn: the rapid experiment and learning cycle as used in Lean Startup to rapidly validate assumptions and learn/fail fast.

Burndown Chart: a regularly updated and visible graph showing the quantity of work remaining (vertical axis) against elapsed project time (horizontal axis). See Release Burndown Chart and Sprint Burndown Chart.

Burnup Chart: a visible graph showing the amount of work completed in each sprint against a ceiling of all of the work to be done for a release. Release burnup charts were in common use for Scrum until the Alternate Release Burndown Chart was invented.

Business Model Canvas (BMC): a strategic management and entrepreneurial tool to describe, design, challenge, invent and pivot a business model. This lean startup template is used to develop new or document existing business models. The canvas is downloadable from the Strategyzer site.

C

Capability Maturity Model Integration (CMMI): a commercial training and appraisal service for process improvement. The maturity levels attainable are Initial (level 1), Managed (level 2), Defined (level 3), Quantitatively Managed (level 4) and Optimising (level 5). Agile and CMMI are compatible methods for identifying and implementing good practice, this is demonstrated by existing companies developing Agile projects at CMMI level 5 (optimising).

Capability Maturity Model for Software (SW-CMM): a process improvement approach for software. SW-CMM was first released in 1991 and was subsequently replaced in 1997 by CMMI.

Cognitive Bias: a subjective reality that individuals have where their perception can cause them to collect the wrong data or misinterpret it. There are a large number of cognitive biases identified which can be adaptive and enable faster decisions but others are factors of human-processing limitations. Examples include:

  • Confirmation Bias: the tendency to interpret data in a way that confirms one’s preconceptions.
  • Framing: the use of too-narrow an approach or description of a situation or issue.
  • Hindsight Bias: the inclination to view past events as being predictable.
  • Self-serving Bias: the tendency to claim more responsibility for successes than failures.

Collective Code Ownership: the convention on Agile teams that no single person ‘owns’ any piece of code with the duty for every team member to implement changes across the code-base as required. Collective code ownership acts to share technical knowledge, encourages collective team responsibility and reduces the risk of a single develop stalling progress.

Community of Interest (CoI): a community of people sharing a common interest or passion. They exchange ideas and thoughts regarding the given area but may not know or interact outside of this.

Community of Practice (CoP): a group of practitioners who share a common interest, problem or passion. Its members participate in the community to share ideas, resolve issues and improve their understanding of the subject area. Participation is voluntary, entertaining, compelling, interesting, long-term and not restricted by location.

Consumption Map: a business tool for capturing how your customers experience your product. It identifies the touch points that they have with your product and links them into a chain. This should be repeated for each product life-cycle phase and used to identify short-term improvement measures and to prepare for each stage and set of customers.

Continuous Delivery: similar to Continuous Deployment with the exception that a human intervention is required to promote changes into a subsequent environment along the pipeline. Scrum teams often deliver each Sprint and product owners then decide when to deploy the developed product.

Continuous Deployment: a fully automated process to deploy each individual product change to the production environment without human intervention. Continuous deployment requires extensive automation, instrumentation, phased delivery and an infrastructure that allows changes to be easily and quickly backed out.

Continuous Integration (CI): the practice of automatically building code as it is checked in. performing all automated testing and notifying the team of the results. CI should be linked to an automated dashboard to show the current build state. Broken builds slow down development and reduce trust, CI enables faster feedback and accountability.

Cross-Functional: ideally an Agile team should contain all of the skills required to take the product from concept to cash. See T-Shaped People and Generalising Specialist.

Cumulative Flow Diagram (CFD): a tool for tracking and forecasting work within Kanban and Lean. A CFD data visualisation shows, over time, the amount of work within each stage. This data allows lead time and cycle time to be calculated and aids in identifying bottlenecks and other issues.

Cycle Time: the amount of time from when work begins on a change request to when it is ready for delivery. Cycle time measures process capability.

D

Daily Scrum: in Scrum this is the daily team co-ordination event of 15 minutes or less.  Typically team members will each answer three questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The discussion, typically around a task-board may result in updates to the sprint backlog. Note that other names used include ‘daily stand-up’, ‘daily meeting’, ‘huddle’ and ‘roll-call’.

Dark Scrum: Abusive forms of Scrum where the framework is misapplied in order to oppress and exert power over developers. This term was introduced by Ron Jeffries in September 2016.

DEEP: an acronym to summarise the key attributes of a good product backlog:

  • Detailed Appropriately: Product Backlog Items that are to be implemented soon need to be sufficiently detailed to be taken into a Sprint. Items for later sprints are less detailed.
  • Estimated: Every item within the backlog must be estimated, larger items further down the backlog will have less precise estimates than the smaller items at the top. Estimation units include story points or ideal hours.
  • Emergent: The backlog should be constantly evolving as more is learnt with items being split, added, removed, detailed or reordered.
  • Prioritised: The Product Owner orders the backlog so that the most valuable items are at the top with development value maximized by the team working down the ordered backlog.

Definition of Done (DoD): a shared agreement of the list of criteria that must be met by any user story before it is consider ‘done’. The DoD is a quality bar for work to be delivered within the sprint and is wholly owned by the development team. Ideally the DoD should be the final bar to a product backlog item being releasable, due to this try to avoid Done-Done. The DoD adds a layer of transparency so that the PO, SM, Developers and customers all agree on what is considered a completed item,. Note that individual DoD checklists may exist for stories, sprints and releases, additionally if a user story does not meet the DoD then it is not counted in the velocity and is instead returned to the Product Backlog.

Definition of Ready (DoR): a shared agreement of the list of criteria that must be met by any user story before it is permitted to enter the sprint. The DoD is a quality bar for work to be planned into a sprint and is wholly owned by the development team. The DoD protects the development team from poorly constructed stories that could slow down the team, it also details what is required to the product owner when generating stories. DoR are generally based upon the INVEST acronym.

Development Team: the developers within a Scrum team are responsible in each sprint for organising and performing all development work required to generate a potentially releasable product Increment. Developers should be cross-functional and self-organising as well as empowered, focused and motivated. Ideally each developer is fully allocated to a single project.

DevOps: is the practice of explicit collaboration and communication between Development and Operations to automate and improve software development, delivery, infrastructure change and operational support. DevOps covers the entire delivery pipeline to lead to faster time to market, lower failure rate, shorted defect fix time and faster time to recovery in the event of a failed new release.

Discipline Agile Delivery (DAD): an incremental and iterative process decision framework for lean enterprises. The DAD framework was created by Scott Ambler and incorporates Scrum, Agile Modeling and Lean Software Development. DAD uses and inception phase, construction phase and transition phase. Note that the delivery part of the name has recently been dropped leaving us with Disciplined Agile (DA).

Dojo (Japanese: Training Place): a coding club in which to practice exercises (Kata), often by group practice.

Don’t Repeat Yourself (DRY): pragmatic programming principle where ‘ever piece of knowledge must have a single, unambiguous, authoritative representation within a system’. Avoid WET solutions – ‘we enjoy typing’, ‘waste everyone’s time’ or ‘write everything twice’.

DSDM (Dynamic Systems Development Method): an Agile project delivery framework first released in 1994 to provide discipline to rapid application development (RAD). It has to be said that in 2016 DSDM is no longer a popular Agile delivery method. See the DSDM consortium site for further details.

E

Eliminate-Reduce-Raise-Create (EERC) Grid: a business tool encouraging the identification of features that should be reduced or eliminated in conjunction with those that should be improved or created. The four grid quadrants are:

  • Eliminate: Which factors that the industry has long competed on should be eliminated?
  • Raise: Which factors should be raised well above the industry’s standard?
  • Reduce: Which factors should be reduced well below the industry’s standard?
  • Create: Which factors should be created that the industry has never offered?

Emergent Design: by minimising up-front design Agile teams are able to continually refine and add to the product design whilst delivering high-value product increments. The least you know of a product is when you start so why would you perform all of the design up-front. Create as much of the architecture and design as you need to begin the project and then develop it as you work through.

Empiricism:  process control can be defined where decisions are made according to a hard process and plan or empirical (such as in Agile) where decisions are based upon the current state of the product and the experience in reaching that point, The three pillars of  empiricism are Transparency, Inspection and Adaption and these are seen through Agile practices

Enterprise Unified Process (EUP): an extension to the unified process to include two additional phases – production and retirement; and add additional project and enterprise disciplines. Developed by Scott Ambler and Larry Constantine in 2000 EUP was evolved in 2013 to build on from Disciplined Agile Delivery.

Estimation: a quantified evaluation of the effort required to complete a given task. There are many schools of thought on estimating in Agile, the #noestimates movement is interesting but generally duration in ideal hours or story points is used. Estimates in Agile are created by the whole team to improve accountability; planning poker and affinity estimation are popular methods for performing this.

Exploratory Testing: a practice where the tester’s autonomy, skill and creativity is utilised to identify areas at risk and evolve scenarios to find issues. In contrast to scripted testing there is a short declaration of a minimum test charter containing the time-boxed scope, objectives and possible approaches to be used.

Extreme Programming (XP): a development methodology intended to improve quality and responsiveness to customer needs. XP is based on taking an extreme approach to all engineering practices to drive higher-quality customer-focused development. XP is often used as the low-level software development practices within the Scrum framework.

F

Facilitation: an important practice in Agile, frequently performed by a Scrum Master in Scrum, to create the conditions for effective group collaboration. A facilitator will design and run meetings without providing active input into the discussions.

Fail: acronym – First Attempt In Learning.

Fail-fast: an approach to developing a product that embraces using small experiments to gain fast feedback and then rapidly inspecting and integrating. With high levels of uncertainty it is often better to try an idea with minimum risk and expense and then if required, kill it fast before further money is spent. This is less confrontationally called fast-feedback or learn-fast.

Feature Driven Design (FDD): an iterative and incremental software development process for identifying and developing small, client-valued functions expressed in the form <action><result><object>. The FDD lifecycle is as follows –

  • Develop an Overall Model
  • Build a Features List
  • Plan by Feature
  • Design by Feature
  • Build by Feature

Feature Toggle: software development practice that allows dynamically turning (parts of) functionality on and off without impacting the overall accessibility of the system by its users. Different categories of feature toggles include release toggles, experiment toggles, operations toggles and permissioning toggles.

Five S Methodology (5S): workplace organisation method based on five Japanese words –

  • Seiri: Sort – removal of unnecessary items and removal of obstacles.
  • Seiton: Systematic Arrangement – arrange necessary items to make workflow smooth and easy.
  • Seiso: Shine – keep the workplace safe and easy to work within plus use the cleaning process to also maintain required equipment.
  • Seikutsu: Standardise – create processes to reinforce good practice, maintain orderliness and organisation.
  • Shitsuki: Sustain – perform training and regular audits to keep the workplace efficient.

FrAgile: simply ‘Agile in name only’ where Agile practices are performed without rigour or discipline. FrAgile provides an excuse for poor quality development avoiding accountability.

Functional Spike: a backlog item/user story used where there is significant uncertainty as to how a user might interact with a system. Functional spikes normally utilise some form of prototypes to elicit end-user feedback. The output from the time-boxed spike should be clarification of the desired functionality or customer need.

Gemba (Japanese: Workface): the place at which value is created, the (ideally) colocated team area. Management visit the workplace, look around and ask questions to understand what is being done (gemba walk).

GE-McKinsey Matrix: a systematic approach for a business to prioritise investments. The 3×3 matrix has columns showing business unit strength (high, medium, low) and rows representing industry attractiveness (high, medium, low). The strength and attractiveness are calculated using suitable criteria and then each business unit is shown as a circle with market size as the size, market share as a pie chart and the expected future position as an external arrow. This allows for each business unit to be identified as Grow, Hold or Harvest.

Genchi Genbutsu (Japanese: Go and See): similar to management by walking around, the principle is going to the source to find the facts, make decisions and build consensus to achieve the correct goal.

Generalising Specialist: a person with a technical specialism in addition to general knowledge in development and business areas. Additionally they actively seek to gain new skills in both their own specialties and additional areas of the business.

Given-When-That: a template used for writing acceptance tests for user stories in Specification By Example –

  • The Given part describes the state of the world before you begin the behaviour you’re specifying in this scenario. This is the context or pre-conditions for the test.
  • The When section is that behaviour that you’re specifying – the actions to be performed.
  • Finally the Then section describes the observable consequences that should occur – the changes expected due to the specified behaviour.

H

Hansei (Japanese: Self-Reflection):  recognise and reflect upon mistakes in order to not repeat them. To objectively and critically evaluate tasks to find avenues for improvement.

Heartbeat Retrospective: a regular meeting, normally aligned to iterations, to reflect on the significant events that have occurred and to decide on what remediation or improvements to implement next. In Scrum this is the Sprint Retrospective, alternatively called a reflection workshop, debriefing or post-mortem.

HiPPO (Highest Paid Person’s Opinion):  the tendency for lower-paid employees to defer to higher-paid employees when a decision needs to be made. Additionally covering the practice of relying on human instinct instead of data in the decision-making process. HiPPOs come with the best intent but their opinion should be balanced by actual data created by research and validation.

I                                    

Icebox: an area for user stories that have not yet been ordered (prioritised).

Idea Board: An area for team members to write new ideas at any point instead of awaiting sprint retrospectives. Also including successfully implemented ideas reinforces positive behaviours. Also called an innovation board.

Increment: the total work completed within a Sprint plus all of the work delivered in previous Sprints. Only work that meets the Definition of Done can be included within the new Increment and it should ideally always be deployable.

Incremental Development: each successive version of the product is deliverable and each builds upon the previous version. Incremental development has ‘vertical slices’ of functionality (feature driven) that build on each other instead of component based development where individual components have no explicit value independently.

Information Radiators: the public display of information in a highly-visible location so that anyone can see and comment upon it. This can be hand-written, printed or electronic and could be dashboards, charts, metrics or task boards. Also called Big Visible Charts and used within Informative Workspaces. This is opposite to Information Fridges where information is hidden and cannot be seen within specific access.

Innovation Ambition Matrix: a business tool to evaluate a business’s innovation portfolio (see Bansi Nagjo and Geoff Tuff’s original article in the Harvard Business Review. On the chart the horizontal axis is titled How to Win and the vertical axis Where to Play, within these are three graphed innovation areas:

  1. Core– Optimising existing products for existing customers.
  2. Adjacent– Expanding from existing business into ‘new to the company’ business.
  3. Transformational– Developing breakthroughs and inventing things for markets that don’t yet exist.

INVEST: acronym used to assess the quality of a user story –

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small or appropriately sized
  • Testable

Iteration: a timebox in which development is performed. An iteration should be thirty days or less and is generally fixed for the duration of a project. Iterations allow velocity to be calculated and are an effective way of breaking up work and focusing on producing product increments.

Iterative Development: the practice of running regular fixed-length development activities. Development activities are performed for each sprint, for example planning, backlog refinement and review. Kanban does not use iterations in the sense of time-boxed sprints but still has repeated activities revisiting the same product areas.

J

Jidoka (Japanese: Managed Automation): automating processes to stop when an abnormal condition occurs to allow a developer to eliminate the root causes of an issue. Automation with a human touch has the steps detect, stop, fix immediate concern and investigate in order to prevent future issues. Continuous integration is an example of Jidoka enabling quality to be built-in.

Just Barely Good Enough (JBGE): sufficient for the current situation but no more, this is an application of the KISS principle.

K

Kaikaku (Japanese: Radical Change): making fundamental and radical changes to the production system. This is different to Kaizen which focuses on minor incremental changes.

Kaizen (Japanese: Continuous Improvement): change for the better with small improvements over time accumulating into big results. The retrospective in Scrum is the key point at which to identify improvements and drive the improvement cycle.

Kanban: a method for managing knowledge work with an emphasis on just-in-time delivery whilst not overloading team members. David Anderson introduced the Kanban method for software development in his 2010 book Kanban.

Kanban Board: a work and workflow visualisation tool to enable teams to optimize development. Physical Kanban boards typically use Post-it notes to communicate status, progress and issues. Electronic boards utilise the whiteboard metaphor to visualize work.

Kano Model: a business tool used differentiate your product. The graph looks at two dimensions with the horizontal axis depicting the degree to which a feature is provided (not implemented – fully implemented) and the vertical axis showing the resultant customer satisfaction (dissatisfied – satisfied). The model allows basic features to be identified in addition to performance features and delighters.

Kata (Japanese: Individual Training Exercise): a short exercise to practice upon to improve your ability in problem solving, innovation and coding discipline. Sets of standard coding kata are available so that you can gauge your ability against others. Frequently coding the same pattern allows different methods to be experimented with and the short feedback cycles drive improvement.

Keep It Simple Stupid (KISS): the design principle that systems work best if they are kept simple rather than more complicated. The acronym is attributed to Kelly Jonhnson, lead engineer at the Lockheed Skunk Works. Einstein had a similar view, “Make everything as simple as possible, but not simpler.

L

Lead Time: the total amount of time from the initial change request to final delivery. Lead time measures what the customer sees.

Lean: a methodology to maximise customer value whilst minimizing waste, lean seeks to create more value for customers quicker whilst using fewer resources. A lean organisation understands customer value and focuses its key processes to continually increase it. The ultimate goal is to provide perfect value to the customer through a ideal value creation process that has zero waste. Lean comes from the Toyota Production System and has a software variant called Lean Software Development. Its pillars are respect for people and continuous improvement on a foundation of manager-teachers in lean thinking.

Lean Startup: a method for developing businesses and products created by Eric Ries in 2008. By adopting a business hypothesis-driven experimentation, iterative release and validated learning, market risks can be reduced and value maximised.

LeSS (Large Scale Scrum): a product development framework for scaling Scrum. Created in 2013 by Craig Larman and Bas Vodde, LeSS consists of principles, rules, guides and experiments. LeSS focuses on understanding a single Scrum team and scaling up (bottom-up scaling). There are two frameworks in LeSS, the first (basic) operates for up to eight teams and the second (LeSS Huge) scales up to thousands on a single product. See the LeSS website for further details.

Lipstick Agile: Agile practices cosmetically applied without any understanding or noticeable difference to the true nature of development. You can put lipstick on a pig, but it is still a pig.

Littles Law: a theorem in Queueing Theory by John Little that states “The long-term average number of customers in a stable system (L) is equal to the long-term average effective arrival rate (A) multiplied by the average time a customer spends in the system  (W), or expressed algebraically L=AW“. This is critical for analysing work flow through a system and is heavily used in Kanban and Lean.

M

Management 3.0: the application of modern management and leadership practices within Agile development. Management 1.0 is scientific management, the command and control top-down hierarchies that were traditionally in place. Management 2.0 includes fads many additional practices such as six sigma and total quality management, all intended to bolster top-down management and better design organisations. Management 3.0 introduces complexity and modern holistic practices focused on people and their network of relationships.

Milestone Retrospective: a broader retrospective generally facilitated by someone external to the project team to analyse the projects significant events. This is different from an iteration retrospective as the entire project team attends for one to three days with the focus on long-term or strategic viability, working relationships or governance concerns.

Minimum Feature Set: see Minimum Viable Product.

Minimum Marketable Feature (MMF): the smallest unit of functionality that can be delivered which has value to the organisation and to the end users.

Minimum Marketable Product (MMP): a product containing the smallest possible set of features that addresses the end users’ needs and can be marketed and sold successfully. MMP is used to reduce time-to-market.

Minimum Valuable Product (MVP): a less popular and more recent alternative to Minimum Viable Product focused more on producing a product with the highest return on investment versus risk. The viable focus is on learning in a deploy first, code later model where a hypothesis is being tested; the valuable focus is on producing value for the users, project and business. Please don’t use this acronym due to the potential for confusion.

Minimum Viable Experiment (MVE): a recent and less popular alternative to Minimum Viable Product, created to clarify what the MVP should really be used for – an experiment to validate a hypothesis and learn more about the customer’s needs – NOT the smallest product that can be launched.

Minimum Viable Product (MVP): “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” – Eric Ries. MVP is a learning vehicle and is used for risk reduction by learning more about the customer’s needs and avoiding spending time developing the wrong product. Also called a Minimum Feature Set by Steve Blank.

Modelling Board: Agile modelling allows groups to gather around a whiteboard to create and evolve a model for the system being developed. This is a quick and easy method that allows wider involvement and input post-meeting by others who see the board. Also called a Design Board.

Mood Marbles:  a method for gauging the emotional state of an Agile team. A bowl of marbles (red, amber and green) is placed alongside an empty jar within the team space, ideally somewhere on the exit path. Team members individually place a marble into the jar as they leave each day to indicate their emotional state for the day (positive – green, neutral – amber, negative – red). The jar is taken along to the retrospective and the distribution discussed. Not that an electronic version using mobiles is also available with better granularity.

MoSCoW: a prioritisation technique acronym sometimes used for ordering work for releases:

  • Must have – MUST is itself an acronym of Minimum Usable SubseT.
  • Should have
  • Could have
  • Wont have

N

Nexus: a Scrum-based open framework for developing and sustaining scaled product development initiatives. Consisting of roles, events, artefacts and the rules that bind them together Nexus was created in August 2015 by Scrum co-founder Ken Schwaber and Scrum.org. See the Nexus guide on the Scrum.org website for further details.

Niko-Niko Calendar: a physical calendar on one of the team walls where each member records at the end of each day a graphic evaluation of their mood in the form of an emoticon, smiley or appropriate sticker. Over time this information radiator plots the team’s emotional state and helps in analysing patterns of change. Note that this is also called a feedback wall, smiley calendar, happiness door or happiness index. Alternatives such as Mood Marbles are also popular.

#NoEstimates: a popular movement removing the need to estimate and instead focuses on rapidly delivering small sets of features incrementally. Estimation is difficult, inaccurate and time consuming, by instead focusing product development on prioritising and delivering features we can produce more value.

O

Obeya (Japanese: War Room): a room used to display all project charts and plans. Acts as a single location for the team in optimising a project. The visualisation and shared space improves a team’s interaction and ability to plan.

Objectives and Key Results (OKR): a method for defining and tracking objectives and their outcomes. OKR structure has 3-5 objectives on company, team or personal levels and 3-4 measurable and quantifiable results.

Open Space Technology (OST): an approach to hosting meetings, conferences and retreats where purpose-driven leadership is used to solve problems without beginning with a formal agenda. OST events contain the following stages –

  • Opening Circle with a short introduction followed by the agenda co-creation.
  • Facilitator’s explanation of principles and format.
  • Multiple conversations are held around the same big space with attendees participating in those they believe they add value to.
  • Closing circle for comments and reflection.

Open Unified Process (OpenUP): an open source process framework began in 2005 with the donation of the Basic Unified Process (BUP – a subset of RUP) from IBM. OpenUP is targeted at small projects of 3 to 6 people and 3 to 6 months of development effort.

P

Pair Programming: the practice where two team members jointly create new functionality. Sharing a workstation the ‘driver’ uses the controls whilst the ‘navigator’ focuses more on the overall direction. Several different models of pair programming exist with control being passed between the pair regularly, either based on duration or on a TDD red, green, refactor cycle. An advantage of rotating pairs is that knowledge is spread rapidly through the team, avoiding knowledge silos.

Pareto Principle: in general around 80% of the effects come from 20% of the causes. This is also called the 80/20 rule, the law of the vital few and the principle of factor scarcity. Examples include:

  • 80% of a company’s profits come from 20% of its customers.
  • 80% of a company’s sales come from 20% of its products.

and from proven examples –

  • Microsoft eliminated 80% of errors and crashes by fixing the top 20% of most-reported bugs
  • 82.7% of world income (GDP) is controlled by the richest 20% of the world’s population.
  • In financial services, 20% of a company’s customers are generating income whilst 80% are costing the company money.

Personal Software Process (PSP): a proprietary structured software development process to apply the principles of CMMI to a single developer. PSP has several maturity levels akin to CMMI and fits within the Team Software Process.

Personas: a fictional biography of a potential user of the product (“make up pretend users and design for them” – Alan Cooper). Personas provide a concise and visual representation of the people that you believe will use the product, it is important to create a user to represent each category. Personas are displayed in the team room so that they are visible and can be targeted by design.

Pirate Metrics: a set of metrics to support Lean Startup analytics and validation based on the acronym AARRR – Acquisition, Retention, Referral and Revenue.

Pivot: in Lean Startup a pivot is a structured course correction designed to test a new fundamental hypothesis regarding a product, strategy and engine of growth. Good examples include –

  • YouTube, the Video download site began as a video dating application called ‘Tune In Hook Up’.
  • GroupOn was founded in 2006 as ‘The Point’, a platform for mobilising groups towards action for various causes.
  • PayPal originating as a way to exchange money via Palm Pilots, PayPal now processes hundreds of billions of dollars every year.
  • Twitter began as podcasting startup Odeo that was bypassed by iTunes and began as a side project from a hackathon looking for new opportunities.
  • Flickr the photo sharing application roots lie in the development on an online role-playing game
  • Yelp, the ‘friendster yellow pages’ started as an automated system for e-mailing recommendation requests to friends
  • Instagram began as a Foresquare and Mafia Wars mash-up project to learn programming.

Planning Poker: a consensus-based technique for estimating frequently used by Agile teams. The process for planning poker is as follows:

  1. The product owner provides an overview of the item being estimated and the team are given the opportunity to discuss it.
  2. The facilitator asks the team to pick an estimate based upon the discussion, this is done secretly using planning poker cards (or sometimes fingers…).
  3. The facilitator asks for the team to show their estimates simultaneously.
  4. The members with the highest and lowest estimates present a justification for their choice and this is followed by a short discussion.
  5. This process is repeated until an estimate is agreed. Often if an item is not agreed in three rounds it is removed from the session and worked on before bringing it back into the next refinement event.

There are several refinements of planning poker such as golden stories/reference stories to prevent point inflation and better consensus techniques but this definition provides a starting point.

Poka-Yoke (Japanese: Mistake Proofing): prevent mistakes from occurring or detect them quickly so that they are fixed immediately during development. Examples in software include designing dangerous features out of a language (automatic garbage collection in Java), reminding users there is no title on an e-mail before sending or highlighting invalid commands within an IDE.

Pomodoro Technique: a time management method using a timer to break work into short intervals named Pomodoro’s. Each Pomodoro lasts 25 minutes and is followed by a break. The ‘to do today’ list is drawn up in the morning and then the following steps are taken:

  1. Select the task to be performed from the ‘to do today’ list.
  2. Start the Pomodoro timer with a duration of 25 minutes.
  3. Work on the task until the timer rings, this gives uninterrupted flow and focus. If any distraction happens during the Pomodoro then note it down but continue with the task.
  4. After the timer rings to signal the end of the Pomodoro, put a checkmark on a piece of paper.
  5. If you have fewer than four checkmarks, then take a break of 3 to 5 minutes and return to step 1.
  6. If you have four checkmarks then take a longer break of 15 to 30 minutes, reset the checkmark count and return to step 1.

Power-Interest Grid: a tool to aid in the categorisation of product stakeholders who have power and interest in the development. The grid contains four quadrants and has Interest on the horizontal axis and Power on the vertical axis. The four quadrants are titled differently for each grid style; the following is an example of this:

  • Low Interest & Low Power: Monitor (minimal effort) – keep an eye on this group but do not bore them with excessive communication.
  • High Interest & Low Power: Keep Informed – talk regularly with this group to avoid issues, and listen to their feedback on the detail of the product.
  • Low Interest & High Power: Keep Satisfied – engage with this group so that they remain satisfied but not so much that they become bored.
  • High Interest & High Power: Manage Closely – key stakeholders that need to be fully engaged and collaborated with.

PRINCE2 Agile: an extension module providing guidance on applying Agile methods to the AXELOS PRINCE2 project management method. Introduced in June 2015 this was fourteen years too late, created by a single author, and is a last ditch attempt to make PRINCE2 relevant in a changed world.

Problem Interview: initial customer conversation to validate if we understand the problem that needs to be solved. The focus of the problem interview is:

  1. Problem – what are you solving and how does the customer rank the top three problems?
  2. Existing Alternatives – Who is your competition and how are the problems currently solved?
  3. Customer Segments – Who has the pain and is this a viable customer segment?

Scripts are used to conduct the interview and compare responses. The interviews can be conducted via any medium but follow the following template:

  • Welcome (2 minutes): Set the stage.
  • Collect Demographics (2 minutes): Test customer segment.
  • Tell a Story (2 minutes): Set problem context.
  • Problem Ranking (4 minutes): Test problem.
  • Explore Customer’s Worldview (15 minutes): Test problem.
  • Wrapping Up (2 minutes): The hook and ask
  • Document Results (5 minutes)

Product Backlog: an ordered list of all of the work to be completed for a project or product. The product backlog is owned by the product owner and contains Product Backlog Items in the form of user stories, requirements or any other agreed format. Key attributes of a good product backlog can be summarised by the acronym DEEP (see separate definition).

Product Backlog Item (PBI): an item within the product backlog, this could be in any agreed format such as a user story, requirement or use case.

Product Backlog Refinement: the practice of meeting regularly to refine the product backlog. This can involve re-ordering or removing backlog items, creating new ones or rewriting, re-estimating and splitting existing items. Refinement meetings ensure that the product backlog is kept current and has sufficient work for the team at the right granularity for the next few sprints.

Product Manager: the role responsible for creating and communicating the product vision and driving the development of products within an organisation. Product managers own the high-level product backlog containing all of the work to be performed.

Product/Market Fit (PMF): The degree to which a product satisfies a strong market demand. “PMF means being in a good market with a product that can satisfy that market” (Mark Andreessen).

Product Owner (PO): the role responsible for maximising product value and return on investment for the company. They are also the local customer representative empowered to make timely decisions. Key PO responsibilities include:

  • Collaborating with stakeholders
  • Creating the product vision
  • Owning the Product Backlog
  • Expressing business and functional expectations
  • Planning product releases
  • Managing the budget
  • Driving product success

Product Vision: a brief statement of the desired future state or main goal to be achieved through the development initiative. Creating and communicating the product vision is the responsibility of the Product Manager/Product Owner.

Program Board:  a big visible chart enabling a higher-level view of activities. This can include vision, full idea generation, approval process, engineering and delivery. By including the full life cycle, from concept to cash (Mary & Tom Poppendieck) it is easier to focus on the full life-cycle. Obeya (large room/war room) can give visibility to the entire development process. Also called a portfolio board.

Project Charter: a high-level summary of the project’s key success factors to be displayed on the team room wall. The charter should contain the major objectives, scope and agreements between the development team and stakeholders.

Q

Queueing Theory: the mathematical study of flow – or how items move through a system with waiting lines.  Lean looks at statistical variation and the effects of queueing theory with the levelling principle to reduce variability and small batches and reduced cycle times effecting flow.

R

RACI: a responsibility matrix based on the acronym –

  • Responsible – those who do the work.
  • Accountable – the one person answerable for completion of the task, who delegates it to those responsible and approves it after.
  • Consulted – Those whose opinions and input are sought (two-way conversation).
  • Informed – Those kept up-to-date on progress, often on completion of tasks (one-way conversation).

Rational Unified Process (RUP): an iterative development framework adapted from the Unified Process by the Rational Software Corporation from 1997. RUP is a proprietary framework intended to be adapted by organisations and teams to fit their specific needs.

Ready: a shared understanding of what is required for a product backlog item prior to it being introduced at Sprint Planning. This checklist or quality entry bar is defined within the Definition of Ready.

Ready, Implement, Coach and Hone (RICH): a deployment framework to apply Agile methods and realise an Agile mindset.

Refactoring: the process of changing the design of code without altering its behaviour. Refactoring is used to clarify and simplify code from iteration to iteration and is required due to the incremental and emergent nature of Agile development. Bob Martin – “the Boy Scout Rule tells us we should  leave the code cleaner than when we found it”.

Relative Estimation: a method of estimating items by their comparison to other items of equivalent size. Relative estimating can be performed as silent grouping or affinity estimation and has the benefit of avoiding unwarranted precision and the sin of confusing estimates as commitments. Story points are usually used but alternatives such as tee-shirt sizing, and scales such as fruit or dog points also exist. Note that relative estimation replaces Absolute Estimation.

Release Board: a representation of the current state of the release split by sprints. This can be elaborate with a full breakdown of the backlog into releases, sprints or a more agile breakdown of the current release only with focus only on the next three sprints and then the following three quarters.

Release Early, Release Often (RERO): the development philosophy empathising early and frequent releases to create a rapid customer feedback loop to drive development and improvement. RERO seeks to remove the risk of creating software that no one will use.

Risk Board: a visualisation of the risks present upon a program. As well as identifying the risks, the mitigation activities can be tracked along with a graph of overall risk exposure and trends.

Role-Feature-Reason: a template used for writing user stories with the format:

  • As a…
  • I want…
  • So that…

This is such a popular format it is often called the ‘user story format’ but it should really serve as an initial template to point to the elements needed. Remember the most important part of the story is the conversation around it.

Rules of Simplicity: a prioritised set of criteria by Kent Beck to judge if source code is ‘simple enough’:

  • the code is verified by automated tests, and all such tests pass
  • the code contains no duplication
  • the code expresses separately each distinct area or responsibility
  • the code is composed of the minimum number of components (classes, methods, lines) compatible with the first three criteria

S

SAFe (Scaled Agile Framework): a scaled Lean-Agile development framework created in 2011 by Dean Leffingwell. SAFe is a top-down enterprise framework for developing products. Somewhat unfairly SAFe is seen by many Agilists as heavy-weight, consultant-driven and overly hierarchical. On the positive side the main website and click-through big-picture view is very usable. Now in version 4.0 SAFe is widely adopted and popular with management. See the SAFe website for further details.

Scrum: an iterative and incremental process framework for developing and sustaining products. The name Scrum is from the rugby analogy of a high-performing and cross-functional team, all pulling together and driving in the same direction with a common goal. Scrum comprises of three roles, five events and three artefacts and is defined in the Scrum Guide.

Scrumban: a management framework utilising Scrum as the way of working and Kanban to visualise, understand and improve. Scrumban uses small teams with work organised into iterations and monitored with a visual board. Unlike Scrum it has no defined roles, uses on-demand planning. WIP limits and the pull principle.

Scrum Board: the information radiator for the scrum team that is used to visualise the Sprint progress. Scrum boards are optional and can be physical or electronic, note that they are similar to Kanban boards but do not include some additional elements such as entry and exit criterial and WIP.

Scrum-but: Scrum is “adopted” but dysfunctions are accepted by the team as the standard way of working. The syntax for this is (ScrumBut)(Reason)(Workaround), for example –

  • We use Scrum, but allocating resources doesn’t work here so we often carry over work sprint to sprint.
  • We use Scrum, but it is at the implementation level so we deliver into the test team at the end of each sprint.
  • We use Scrum, but our team needs more direction so we have a team lead instead of a Scrum Master to manage the team and organise the work.
  • We use Scrum, but we are not a trivial web-site so our sprints are twelve weeks long.
  • etc…

Scrumdamentalist: a evangelically pure follower of Scrum practices operating from an ivory tower. Typically with a two-day CSM “qualification” and no experience scrumdamentalists have no view of reality.

Scrum Guide: the official definition of Scrum written by its co-creators Jeff Sutherland and Ken Schwaber.

Scrum Master: an Agile coach within the team who acts as a servant leader to facilitate the Scrum process. It is the responsibility of the SM to:

  • Mentor the team in Scrum
  • Remove impediments
  • Coach the organisation in Agile
  • Grow an ‘inspect and adapt’ culture
  • Facilitate team interactions
  • Protect the team from interference

Note that the Scrum Master is not a team lead.

Scrum of Scrums (SoS): a technique used to scale Scrum to larger product development by each individual team sending an ambassador to participate in a daily Scrum with other teams. The SoS follows the normal daily Scrum format and often have their own board and backlog. The SoS provides a way to coordinate between teams.

Scrum Team: an empowered, self-organising, collaborative and accountable team consisting of the Product Owner, Scrum Master and Development Team.

Scrum Values: the set of fundamental qualities underpinning the Scrum framework, these are Commitment, Focus, Openness, Respect and Courage.

Self-Organisation: teams need to decide how best to achieve the work that they are given instead of being externally directed. From the product backlog the product owner asks the team the what, it is up to the team to decide on the how.

Shu-Ha-Ri (Japanese: Copying-Reflecting-Extending): Stages of learning –

  • Shu: Copying – The beginning stage, concentrating on repeating what is being taught.
  • Ha: Reflecting – Expanding upon basic practices by learning the underlying principles and integrating knowledge from other teachers.
  • Ri: Extending – Adapting and creating knowledge from your own practice and circumstances.

Sign up for tasks: team members choose which tasks they work on during the sprint with an initial selection often made during sprint planning. The selection is usually indicated by annotating the story card on the team board or using avatars temporarily attached to the task. As the team is self-organising it is important for the team to be able to sign up for tasks themselves and ideally as the sprint progresses.

Simple Design: a practice based on the following principles:

  • design is an ongoing activity and includes refactoring plus YAGNI (You Aren’t Gonna Need It)
  • design quality is evaluated based on the rules of code simplicity
  • design should be deferred until the ‘last responsible moment’ so as to include the most information

sKale: a framework for Agile within the human resources department, sKale builds on Scrum to build the organisation, governance, program level and deal with people issues.

Software Release Train: see Agile Release Train.

Specification by Example (SBE): a collaborative practice used in BDD, ATDD and TDR where realistic examples are used in the description of the desired functional behaviour.

Spike: an activity performed within an increment/sprint such as research, investigation, exploration or prototyping where the output is improved knowledge and not customer value. See Technical Spike or Functional Spike for further information.

Sprint: a time-box of one month or less during which a ‘done’, usable and potentially releasable product increment is created. Sprints are consecutive and have consistent durations, note that 65% of Scrum teams use a sprint length of two weeks.

Sprint Backlog: the set of product backlog items agreed for the sprint plus a plan on how to deliver them.  It is a forecast by the development team on what functionality can be completed within the sprint and the work needed to reach the ‘done’ state. The sprint backlog is owned by the development team and is updated during the sprint to be a highly-visible and real-time picture of the work being performed. Teams may decide to break the accepted product backlog items into smaller tasks within the sprint.

Sprint Goal: a brief description of the purpose of the sprint as agreed at the sprint planning event. The sprint goal provides a focus for the scrum team when making decisions during the sprint.

Sprint Planning: at the start of each Sprint the Scrum Team will collaborate to agree and plan the work to be performed within that Sprint. This event is split into two parts:

  • Part 1: What can be done this Sprint? The Product Owner selects Product Backlog items, based upon the team velocity, for inclusion in the Sprint.The Development Team forecast the work for the selected functionality and agree on what to accept.The Scrum Team craft a Sprint Goal, a cohesive objective to be met in the Sprint.
  • Part 2: How will the chosen work get done? The Development Team decide how to develop the Product Backlog items to a “Done” state during the Sprint.Note that the Product Owner does not need to be present for part 2 of Sprint Planning but should be available for questions if required.A Sprint Backlog is created consisting of the Product Backlog items selected for the sprint plus the plan for delivering them.

Sprint Retrospective: after each sprint there is a formal opportunity for the scrum team to inspect how the last sprint went and identify potential improvements. This event enables the ‘inspect and adapt’ cycle each sprint, allowing the scrum team to consider process, communication, relationships and tools. The scrum team collaborate to identify and prioritise potential improvements. An improvement plan is created to focus on how to achieve the identified improvements. It is important to agree which potential improvements are to be performed in the following sprint.

Sprint Review:  at the end of each sprint is an informal review where the scrum team and product stakeholders collaborate on what was completed in the Sprint and what to do next. This event is an opportunity to inspect the work done and revise the Product Backlog as required. Generally only items completed (done) during the sprint should be shown. The goal of the Sprint Review is to gain feedback to maximise value and return on investment. Finally, the Product Owner discusses the state of the Product Backlog, updates the Alternate Release Burndown Chart and presents likely completion dates based upon the progress made. Note that the sprint review is not a demo or a show-and-tell.

Stakeholder:  a person outside of the scrum team with a specific interest in the product development. The stakeholders are represented by the product owner and collaborate with the team at the sprint review.

Story Splitting: a user story needs to be small enough prior to be taken into a sprint and will need to be split to ensure this. Various techniques exist to split stories to ensure that measurable business value is still ensured.

Story Mapping: a structured approach to release planning with user activities along the horizontal axis and increasing sophistication of the implementation down the vertical axis. With a story map the first row represents a walking skeleton, a barebones but usable version of the product (possibly an MVP). Successive rows flesh out this skeleton with existing functionality.

Strategy Canvas: a business tool to graphically map the current strategic landscape and the future prospects for a company. The horizontal axis captures key factors your industry competes upon, and the vertical axis describes the degree to which each competitor offers or invests in these factors. This can then be used to differentiate your product from your competitors and adding factors where there is no competition (blue market/blue ocean).

Sustainable Pace: teams should be able to work indefinitely at the rate they are currently at. Realistically this means avoiding overtime on Agile teams with the exception of at short (less than a month) and very targeted times.

T

Task Board: a physical or electronic location for the team to monitor the development work being performed. Task boards often divided into columns, for example ‘To Do’, ‘In Progress’ and ‘Done’ with tasks being represented by Post-it notes and moved left to right as work progresses. The task board acts as a focus for the team and is often where teams meet for their daily coordination meeting.

Team: a small group allocated (ideally) full-time to a project containing all of the skills required to take the product from concept to cash. In Scrum this would be three to nine developers plus a product owner and scrum master. Teams are empowered, self-organising, cross-functional and (ideally) collocated.

Team Room: a dedicated space for use by a team furnished with everything that the team need such as pairing workstations, whiteboards, flipcharts, wall space etc.

Team Software Process (TSP): a proprietary operational process framework, building upon the Personal Software Process, to improve quality and productivity whilst developing software products. Although promoted by the Software Engineering Institute since the late 1990s, it is doubtful if TSP will ever be widely adopted

Technical Debt: the work that would needs to be performed on the code base to reach the desired quality. Technical debt is often accrued by business pressure, lack of process or understanding, lack of a comprehensive automated test suite, parallel development, delayed refactoring, poor technical leadership, last-minute specification change or scope doping. Technical debt will slow down development and increase defects. Tools exist to identify technical debt and to aid refactoring.

Technical Spike: a backlog item/user story used to research technical approaches on a product in order to develop a better understanding of the desired approach. The output from the time-boxed spike should be better knowledge of the desired approach.

Test Driven Development (TDD): a practice of test-first software development where a test case is created first, just enough code is created to pass the test, refactoring is performed and the cycle is repeated:

  1. Write a single unit test detailing an aspect of functionality
  2. Run the test which should fail as the program lacks that feature
  3. Write just enough code in the simplest way possible to pass the test
  4. Refactor the code to comply with the simplicity criteria
  5. Repeat, accumulating tests over time.

Note that this is often called the Red-Green-Refactor cycle.

Three Amigos: a specification workshop where the business analyst presents features for review by a member of the development team and a member of the quality assurance team. The aims are to ensure:

  • Collaborative requirements – a common understanding of what needs to be built
  • Collaborative tests – all team members contribute to the testing of the feature
  • Ready for dev consensus – pull versus push – features are pulled into the sprint when they have been reviewed and accepted by the 3 Amigos.

Three C’s: the components of a user story can be summarised as:

  • Card – user stories are written on cards (such as Post-its or index cards). This contains enough text to identify the requirement and acts as a token for planning.
  • Conversation – a discussion of the card over time by interested parties, ideally face to face.
  • Confirmation – the acceptance criteria for the story to demonstrate that it is complete.

Three Questions:  At the daily meeting each team member answers a variant of the following three questions:

  1. What did I do yesterday?
  2. What will I do today?
  3. What is getting in my way?

See Daily Scrum for formal Scrum versions of these three questions.

Three M’s of Lean: The three enemies of Lean are –

  • Muda: Waste – activities not creating value. Reducing waste is a key just-in-time method to improve profitability.
  • Mura: Unevenness – unfair demands on process, machines and employees reduces overall productivity.
  • Muri: Overburden – unnecessary stress to process and employees. This is targeted by the Agile manifesto with sustainable development and a constant pace.

Timebox: a period of time, agreed previously, in which to perform a task and meet an objective. Timeboxes are used at 25-minute segments for the pomodoro technique thorough to release increments. The critical part of a timebox is to stop when the end is reached and review what progress has been made.

Tragile (Traditional Agile): Confusing abbreviation for a hybrid framework combining both traditional and Agile approaches within the same project. To be honest Traditional Agile fits the definition of Tragic Agile so perhaps not quite so confusing after all.

TrAgile (Tragic Agile): where Agile practices are nominally in place without any understanding or improvement. These tragic situations mimic some of the practices but lack any of culture, mindset change or resultant benefits. For example, Daily Scrums that contain 32 people, last an hour and where everyone gives a status report according to a Microsoft project plan.

U

Ubiquitous Language: a common language developed between developers and users to express requirements in the specific domain. Used in domain driven design ubiquitous language should evolve as understanding between the different groups grows.

Under Promise, Over Deliver: ensure that you can deliver on forecasts by committing to a smaller workload than you believe you can complete and then finish early.

User Story: a short and simple description of a feature from the perspective of the end user. User stories often follow the Role-Feature-Reason format, are written using the INVEST criteria and follow the Three C’s convention.

V

Value Proposition Canvas (VPC): a Lean Startup tool used to design products and services that your customers actually want. The VPC shows the pains, gains and jobs for the customer segment plus the pain relievers, gain creators and products & services within the value proposition. The canvas is downloadable from the Strategyzer site.

Vanity Metric: any metrics gathered and shown that are not actionable and serve to make us feel better or show off. If a metric being collected is not valuable then stop collecting it.

Velocity: an indication of the capacity of an Agile team to complete work. At the end of each iteration the estimates of all delivered items is totalled to give the team’s velocity. Velocity can be taken from a single sprint or averaged across a number of sprints to improve accuracy. A team’s velocity can allow them to better plan sprints and releases.

Voice of the Customer (VOC): a market research technique to produce a detailed set of customer needs, organised into a hierarchical structure and prioritised in terms of relative importance and satisfaction with current alternatives. Also the Product Owner in Scrum who acts as the voice of the customer.

V2MOM: a management guideline acronym used to communicate vision and objectives –

  • Vision – What do you want to do?
  • Values – What’s most important about that vision?
  • Methods – How do you get the job done?
  • Obstacles – What challenges, problems, and issues might stand in the way?
  • Measures – How will you know when you’ve succeeded?

W

Wagile: a hybrid of Waterfall and Agile development practices resulting from either desperately trying to save failing projects or from slipping back from Agile back into Waterfall. By completing a number of short waterfalls, teams delude themselves into thinking that they are still Agile. At best this is adding shorter iterations, Agile walls and stand-ups to failed Waterfall projects in order to reduce the overall risk and appease management. You will definitely notice that retrospectives are either rarely used or less honest.

Waterfall: an outdated and failed sequential defined-process development methodology originating in Winston Royce’s 1970 paper ‘Managing the development of large software systems’. Widely replaced from 2001 onwards by the empirical-process Agile philosophy J

Watermelon Metrics: Green on the outside, but red on the inside. This can lead to gaining a false sense of security from seeing a green dashboard when realistically there is an underlying sea of red. This is generally the unintentional way that a dashboard is configured but could be deliberate selection of automated data in order to represent a false picture.

Water-Scrum-Fall: a failed implementation of Agile where requirements gathering is completed first and then teams perform the implementation prior to the results being passed to the deployment team for eventual release.

Work in Progress (WIP): the amount of work started but not yet finished, this shows waste in the system. Setting WIP limits for each process state enables smoother flow of value.

Worse is better: the belief that quality does not necessarily increase with functionality. At some point, less functionality (worse) is a preferable option (better) for practicality and usability. Software that is limited but simpler to use can be preferable to the customer. The model proposed has the following characteristics (in descending order of importance) –

  • Simplicity: Simplicity is the most important consideration in a design.
  • Correctness: – The design should be correct but it is slightly better to be simple than correct.
  • Consistency: The design must not be overly inconsistent.
  • Completeness: Completeness can be sacrificed in favour of any other quality.

X

XP: See Extreme Programming.

Y

YAGNI (You Aren’t Gonna Need It): an XP principle to avoid adding functionality until it is necessary. “Always implement things when you actually need them, never when you just foresee that you need them” – Ron Jeffries.

Z

Zen: A meditative and absorbing state of mind… (It is amazing how difficult it is to think of a truly Agile term that starts with the letter Z).

Zombie Agile: the blind adherence to Agile practices without the adoption of the mindset required to make them work.