Agile lexicon

The goal of this Lexicon is to provide 18F and our partners a common language for discussion of Agile processes. The definitions are as simple, flexible, and inclusive as we could make them.

High Level Concepts

Agile - pertaining to the Agile Manifesto and/or Agile Principles (http://agilemanifesto.org). Agile is a set of values and principles that describe a way of working that promotes continuous learning and user-focused value delivery.

Agile Disciplines

Lean UX - a set of design principles which includes early customer validation, collaborative design, defining key success metrics (for more info see: Lean UX manifesto).
Scrum - a framework for Agile product development centered around self-organizing team, customer focus, and responding to change.
XP (Extreme Programming) - an agile software development approach that emphasizes business results first, using pair programming and test-driven development, delivering value continuously
Kanban - a process management and diagnostic tool that can be used with both Agile and non-Agile environments. A Kanban board can be a helpful tool for introducing a few Agile behaviors to a team less familiar with the methodology.

Roles

Partner - The agency with whom we are working. 18F doesn’t have “clients,” we have partners. We deliver something together with agency partner.
Client - When the government hires a vendor to perform services, we are a “client” to that services organization. We cannot delegate responsibility for success to the vendor. In keeping with the Agile principle of small, empowered teams, at least one person from the Client team must be an active part of the Agile team. (For an agency or organization working directly with 18F, see “Partner”.)
Customer - the purchaser of a (digital) product/service.
User - the consumer of a product/service
Product Owner (PO) - owns the product vision and incorporates stakeholder feedback to set priorities and manage the backlog
Stakeholder - an interested party whose buy-in you want (or need) but is not the PO

How we talk about the work:

Prototype - A functional representation of a feature or group of features not meant to be sold to customers, but rather to get feedback from potential users or customers.
Minimum Viable Product (MVP) - The smallest usable thing you need to start validating the actual idea of the business or product. The very first increment of the build/measure/learn cycle (Zappos example in The Lean Startup.) It’s there to help demonstrate the market exists for a particular idea. The term “MVP” means something different to virtually everyone, so be sure to get clarity from the person or persons using the term in conversations.
Release - a usable increment of customer value delivered to users in the wild.
User story - a description of functionality or value written from the perspective of the user. Each story should be made available to users as an incremental improvement; however, it often makes sense to collect a set of user stories that will be promoted or validated together as a release.
Definition of done - A working agreement among the team detailing the standard for achieving a “Done” Product Backlog Item (i.e, user story). This applies to all user stories and includes meeting acceptance criteria.
Acceptance criteria - A set of conditions detailing the functional goals of the user story. This is a user story-specific description of when that story is done. The acceptance criteria could be used to demo the user story or to write an automated test.

Concepts:

Non-Functional Requirements (NFRs) - desired characteristics of a product that do not deliver direct user value, such as load handling, performance, browser compatibility, or responsive design.
Test coverage - the portion of the code that is actually exercised when a certain set of tests are run. Usually expressed as a percentage. Often specified as a quality standard, as in, “you must have 90% code coverage to consider your tests adequate.”
Unit tests - Automated tests that concentrate on verifying that the code works as written, and which act as safety flags in high-churn agile development environments with constant check-ins, changes, and multiple developers in the same code. They are best run automatically as part of every build.
Integration tests - Also called Feature Tests, Acceptance Tests, and Regression Tests, these are tests that validate a complete, integrated software product against its business goals. They test the user-visible behavior of the software.
Continuous Integration - Running automated tests on every code submission, within an integrated codebase.
Continuous Deployment - Deploying software automatically to production if automated tests pass.
User research: a range of techniques are used to understand the target audience and the problems that they have. Contextual inquiry, involving direct observation, is favored over interviews. Usability testing: Observation of people attempting to use a product, prototype or mockup. See Design Method: Usability Testing
Prototype: A term that means something different to everyone. You want to come to common understanding about this word early on in any project; but it should be noted here that prototypes should not be referred to as a deliverable and are best described as a supporting activity that promotes learning.

Process words, how we work:

Sprint - the unit of iteration in scrum: a short, fixed interval in which an agile team commits to and delivers a piece of customer value from the backlog.
Sprint Backlog Item - A more granular item than one one would find in a product backlog. It could be a task, chore, bug, or small or finely sliced user story. These items are usually what you find in a trello or waffle board.
Product Backlog - A prioritized list of user value to be produced.
Scrum Master - the team member who is responsible for the team’s rituals and process, who ensures the team can execute on its commitments by removing blockers and facilitating activities like the daily standup, sprint planning, and retrospectives.
Velocity - Any measure of the value produced during each sprint. Average velocity can help guide time-boxed iterations. Velocity is most useful for planning and tracking purposes and does not measure team productivity or performance.
Daily Standup (aka Daily Scrum) - A short, daily meeting during which the team self-organizes for the day. Never more than 15 minutes. Information exchanged can vary but always covers what each team member did yesterday, what they plan to do today, and what if anything is blocking their work.
Retrospective - A meeting of the whole team held once per sprint, wherein the team reflects on what happened in the iteration and identifies actions for team improvement going forward. This is a critical part of the Agile continuous improvement, as contrasted with a post-mortem which happens only after launch, which limits the opportunity for applying lessons learned.
Kickoff meeting - The meeting held with all stakeholders before work begins. The kickoff meeting helps align the team on the project goal, terminology, the day to day process expectations, and roles and responsibilities.
Waterfall/SDLC - a sequential design process, used in digital development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. Primarily used in instances where requirements are not expected to change and user-designer interaction is not desired. (Source: https://en.wikipedia.org/wiki/Waterfall_model)