The Ultimate Agile Terminology Dictionary

For many traditional teams new to agile methodology, understanding the entire agile process can feel a bit overwhelming. But the best way to conquer being overwhelmed is to be prepared.

We created this Agile terminology dictionary to help you understand the most common Agile terms, and work more efficiently with your team.

And at the very least, you’ll have a new batch of buzzword terms to use in your business vocabulary. 😉

 

The Top Agile Terminology You Should Know

The most important thing for teams to know about agile methodology is that the entire process is built to be iterative and flexible. Because of this shift in mindset, an agile approach also comes with its own vernacular, which is critical to understanding the entire process. Here’s our quick guide to the top agile terminology you should know when working with agile teams.

 

Agile: Agile development is a broad term for many different methodologies that adhere to agile principles.

 

Agile Release Train: An agile release train is an approach to aligning the vision, planning and dependencies of multiple teams by providing cross-team synchronization.

 

Backlog: The backlog is like a running list of all relevant tasks, features, and user stories that the team has to work on. This is like a running to-do list, but it’s constantly updated and re-prioritized. Items in each sprint or iteration (see terms below) are chosen from the backlog.

 

Burndown: Burndown is a measure of what’s remaining in the current sprint or iteration. Ideally, it should reach 0 every time.

 

Business Owner: An Individual or entity who owns a business and is in charge of making all decisions related to profit.

 

Cadence: Cadence refers to how often something is scheduled or occurs. Think of it as a way to keep in “rhythm” with your teams.

 

Cross-Functional Team: This refers to a group of people with different expertise working towards a common goal. Usually a cross-functional team includes people from not only different departments (marketing, design, development), but also different levels of an organization.

 

Daily Scrum: A daily scrum is typically held in the morning and helps a team set the context for all of the work that is to be completed that day. Generally teams hold daily scrums while in the middle of a sprint.

 

Definition of Done: A definition of done refers to when a scrum team has consistent acceptance criteria across all users stories. This helps determine when a user story has been completed.

 

Epic: Epics are almost always delivered over a set of sprints. A team will learn more about an epic through development and customer feedback, and user stories will be added and removed to optimize the team’s time.

 

Fail Fast: This is a strategy of trying something, getting feedback quickly and adapting. This principle works well in high levels of uncertainty as it allows teams to determine right away whether or not they have made a good decision or if they need to kill it fast.

 

Flow: Delivering a constant slow delivery of value to the end customer instead of batching together large releases and dropping them all at once.

 

Iteration: An iteration is a time-boxed amount of work that the team sets out to complete. Ideally, all of the work within this period of time will be 100% completed and the resulting work will be ready to ship at the end of the period. Most iterations run about one week to one month in length.

The iteration most often begins with planning and ends with a retrospective.

 

Kanban: Kanban is a popular framework that is used to implement agile software development. It refers to real-time communication of capacity and full transparency of work. Most times, work items are represented visually on a Kanban board which allows members to see the progress of any piece of work at any time.

 

Lean: The main principle of lean is to reduce any activities that do not provide value. The agile process is a lean method for software development lifecycle.

 

MVP: MVP stands for “minimum viable product” and refers to a product that has enough features to satisfy early customers and to provide feedback for future product development and enhancements.

 

Planning: Planning is the first step in the agile process and this is where the team measures the speed at which they can start turning stuff around. The planning process is key to launching a successful iteration and retrospective.

 

Planning Poker: This term is also known as “scrum poker” and is a consensus-based, gamified technique for estimating development goals. Check out more info on Wikipedia.

 

Product Owner: The product owner is ultimately responsible for translating the needs of the user into actionable development tasks. The product owner creates user stories that explain how features and functionality should work so that the team can complete the relevant work to make it happen.

 

Retrospective: At the end of each iteration, the team will usually hold a retrospective meeting. This meeting is meant to assess the work that was done in the previous iteration, identify any challenges, and make adjustments to the work process.

 

Scrum: Scrum is a specific agile methodology. It’s often seen as the de facto agile development structure, but not the only one.

 

Sprint: (See: Iteration)

 

Stand-up Meeting: These regular meetings are used as a quick way to update all of the team on each member’s individual progress. They’re often held on a daily basis and cover current activity, any pending items, roadblocks, or questions.

 

Story Points: Story points are used in agile methodologies to help calculate how many user stories a team can take in an iteration.

 

Timebox: A timebox refers to a previously agreed period of time during which a person or a team works steadily towards completion of some goal.

 

User Story: These stories are created as a way for product owners to communicate specific functionality to the team. It’s meant to be couched from the perspective of the user and describe a specific action that they will take and/or outcome that should be developed.

A typical user story template may look something like this:

As a < type of user >, I want < some goal > so that < some reason >.

The purpose of the user story is to dissect larger features or functionality into discrete increments that can be implemented in a relatively small window of time and then improved or expanded in future iterations.

For further examples of a user story, we recommend checking out this informative post on the Atlassian blog.

 

Velocity: As the name implies, the velocity is a measure of how fast work is progressing within a sprint or iteration. For most typical teams, this is measured as the number of story points (a measure of effort) completed within a time-boxed iteration.

 

A Few Points Agile Teams Should Keep In Mind When Working With Waterfall-Aligned Teams

 

Of course, the whole agile process doesn’t just flow in one direction. Agilists need to also understand the more traditional, waterfall work style.

Although most experienced teams have likely used some process like waterfall in the past, it still helps to take a look at some of the major differences between the two approaches.

 

  • Expanded time spent in planning and design: Planning and design are seen as separate stages of the work process under waterfall. This means that more time is often spent exploring and scoping a project upfront in an effort to catalog and itemize each of the tasks that will need to be completed during the implementation phase.Because the process, by design, is not iterative, there is perceived to be less room for error or change once the work has begun.
  • Additional documentation and process: Secondly, agile teams should expect that waterfall teams will spend more time documenting and logging specific code and processes. This is largely because of the finite nature of the particular project.Projects that have been scoped and delivered may take several months or even years to complete. And it may be that long–or much longer–before they are ever revisited. This means that having clear and concise documentation is extremely important for ongoing work and maintenance.
  • Non-finite time constraints: One of the most obvious differences between a waterfall and agile approach is the use of time-boxed work blocks. Most agile methodologies place a lot of emphasis on delivering a finished product within a specific period of time. When working with a waterfall team, the time box may not be constrained to any specific number of days, weeks, or months. Rather, the time box is as big as needed to complete all of the tasks that are described within the scope of the project.This can be frustrating as some projects are prone to “scope creep”, which means changing requirements, which results in extend the implementation time window far beyond the initial estimate.What if I run a waterfall-based team and need to work with an agile one? As outlined above, the main difference between agile methodologies and waterfall methodologies is the phased approach that waterfall takes vs a more iterative agile approach. But your waterfall team can implement a similar “agile methodology” in the form of an iterative waterfall, which practices a phased approach but in smaller release cycles.

 

While more and more teams are claiming to use agile methodologies, the fact is that a lot of them are using more of a hybrid model that includes several elements of both agile and traditional waterfall. Learning about an agile process can seem overwhelming at first, but this Agile Terminology Dictionary should help you navigate the waters as you become an agile pro.

Is there any other agile terminology you’d like us to add to the list? Let us know by tweeting us @unitoio!