A Dictionary of Agile Language - PLEASE CONTRIBUTE


The importance of language is inevitable. Finding the right wording, which is expressing exactly what we want to say from a context point of view, but also from a emotional point of view. The agile development space is an area of application, where this comes true notably.

With the dictionary of agile language I would like to create a lineup of agile terms and there counterpart in traditional approaches, which are still very common to many people and projects. For that reason I have started a list, where you can find for each of the items a short explanation, how the new agile terms are meant to provoke a change in mindset:

“People” was “Resources” - agile puts the importance of the contibution of individuals in the center and not the plain workforce

“Investment”, “Bet” was “Project” - agile emphasizes the the process of creating value continuously rather than working towards a given plan

“Supporter”, “Facilitator” was “Manager” - while traditional approaches ask for managing people, who are supposed to ensure goals and progress, agile approaches advocate self-organized teams, which look for leaders, who support them or which can be facilitated to achieve their objectives

“Team” was “Expert” - other than with traditional approaches, where experts have been put in the center of planning, the agile approach is team based, where members have to decide on themselves, how they can contribute the best way (keyword “t-shape profile”)

“Ambition” was “Estimation” - agile teams have ambitions to bring meaningful products to customers following an affordable approach, while traditional teams start with estimates with the intend, to make plans visible and traceable

“Check Point” was “Deadline” - while traditional approaches work towards plans, where deadlines determine the dates, where results are to be delivered, agile approaches consider to have regular check points, where deliverables are challenged, if they are sacrificing needs

“Virtual Coffee” was “Workshop” - whenever people in an agile environment consider to have a problem addressed, they invite for a virtual coffee, where the issue is discussed amongst them, whereas traditional environment ask for the organization of a workshop, where all stakeholders are asked for bringing their input and find a solution

“Increment”, “Iteration” was “Release” - traditional approaches assume, that deliverables need a release process before they can be handed over to customers in a reliable and reasonable way, while agile teams offer frequent increments, where small iterations can be pulled, evaluated, and consumed by customers immediately

“Purpose” was “Task” - traditionalist think that teams need to be told what to do, agilists believe that telling teams the purpose of what is to be build will leave the decision on the approach with them

This list is an initial attempt to create a dictionary of agile language. I hope it will find more contributors and grow - the agile way. I am pretty sure, there is more to add. Please make use of the comments to amend.

  • backlog was specifications or project requirements
  • chickens and pigs was the suits and code monkeys
  • retrospective was the hunt for the guilty
  • stand up was the status report
  • fail-fast was duck and cover
  • scope creep was a change order
  • sustainable pace was unheard of
  • technical debt was never mentioned
  • timebox was two weeks after the money ran out
  • user persona was customer
  • continuous integration was integration hell
  • kano analysis was the highest paid person at the table’s opinion

I should stop now…


Please don’t that is quite a roll. Let’s go with:

  • Andon cord: The moment that FUBAR has happened when everybody panics and someone calls and emergency extraordinary meeting to discuss the “situation”
  • FUBAR: Marine term for F_cked up beyond all reason in contrast to
  • SNAFU: Situation Normal, All F_cked up
  • Stop the sprint: See andon cord…

I’ll try to come up with a few less colorful meanings. I agree that language does matter. I was reading Lullaby Words a couple of days ago. It supports your point, that meaning matters. Different focus, but relevant.


thanks @andycleff for your contribution - it took me a while, but i have transfered your input and few more thoughts from myself into a more extensive “definition” now:

“User Story”, “Backlog” was “Specification” - agile works with prioritized list of functionality expected by users, while traditional approaches work with a documentation describing a big picture and all relevant aspects of a solution

“Chickens and Pigs” was “The Boss” - agile provokes giving power to committed development teams (the pigs) to decide how things are done and restrict influence of requestors contributing the requirements (the chicken) on these decisions, whereas in the traditional setups the boss is the major instance who has the saying what is to be done and how things are done

“Retrospective” was “Lessons Learned” - agile people meet on a regular basis and discuss what works well and what can be improved, while traditional projects ask team members to reflect on issues and improvements after deliveries (releases)

“Stand Up Meeting” was “Status Report” - what is going on, planned next, and hindering progress is discussed in frequent (daily) stand-up meetings in agile processes, whereas the boss is collecting a status and sharing a status report on a regular (weekly) basis to provide updates

“Fail-Fast” was “Acceptance Criteria” - agile provokes to test-run implementations as soon as possible to detect failures and take action immediately, whereas traditional projects define an aligned set of acceptance criteria upfront, which gets verified at the end of a project (deviations are argued and adherent projects planned where necessary)

“User Persona” was “Stakeholder” - in agile people to derive solutions from the situation, challenges, and needs of typical users, whereas in traditional projects stakeholders (like key accounts or project managers) are asked to define the requirements for the solution

“Built-In-Quality” was “Quality Assurance” - the results from a product increment must be potentially shipable is one of the agile paradigms, which implies that teams have to take care for quality from beginning, wheres in traditional approaches quality assurance is a discipline on ist own, where dedicated team test and validate the quality of the results from a project in a subsequent step

New terms, which came up the iterative/incremental approach agile is provoking:

“Continuous Integration”
“Scope Creep”
“Technical Debt”

If you are interested, you can find a full list of items on my blog at https://www.freeagile.org/2017/08/30/a-dictionary-of-agile-language/#.WbgwF7puK8A

P.S. I would want to stay away from stating that traditional approaches are bad compared to agile paradigms - when we all made use of the “traditional” approaches it was state of the art and we claimed it would be the best way to manage software projects.

Agile in 5 words or less?