Have You Ever Found Your Team Members Using Different Terms For The Same Things?

Sept 23, 2021

I cannot begin to tell you how frustrating it is to be in a contentious team discussion when we realize that we are either four names for the same thing or one definition applied to four disparate terms. It would be so much better if we were all talking about the same thing. To accomplish this, we need to have a common understanding of those “things.”

A good starting point is a list of terms and a clear definition for each of them. In other words, a glossary. There are several different Agile glossaries available depending on your chosen approach (Scrum, XP, Scaled Agile, etc.). The glossaries have a lot in common, but also some specific differences. It is important to become familiar with the terms defined by your approach, and to make sure that everyone understands and uses the terms in the same way.

Here are some of the most common Agile terms used in the industry. But remember, being Agile requires a lot more than just common terms. It is a shift in culture and mindset for most companies which requires guidance from someone who has made that shift. So, get help from an ICON Coach or mentor who has experience making the Agile transition to ensure success in your own.

Agile Lexicon / Glossary

Acceptance Test
An acceptance test confirms that a story is complete by matching a user action scenario with a desired outcome. In other words, does the delivered solution meet the customer/user expectations? Acceptance testing is also called beta testing, application testing, and end user testing.
Agile Retrospective
In Scrum, the second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.
Agile Software Development
Agile software development is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping code simple, testing often, getting frequent customer/user feedback, and delivering functional bits of the application as soon as they are ready.
Burndown Chart
The burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress.
In agile software development, a customer is a person with an understanding of both the business needs and operational constraints for a project. The customer provides guidance during development on what priorities should be emphasized. (Called a Product Owner in Scrum.)
Daily Scrum
Each day the ScrumMaster facilitates a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to share the state of the work, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day.
An iteration is a single development cycle, usually measured as one week or two weeks. An iteration may also be defined as the elapsed time between iteration planning sessions. (Called a Sprint in Scrum.)
Planning Board
A planning board is used to track the progress of an agile development project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board located in the development area. Development progress is marked on story cards during the week and reviewed daily. (Also called a Team or Kanban Board.)
Planning Game (XP) or Planning Poker (Scrum)
A planning game is a meeting attended by both IT and business teams that is focused on choosing stories for a release or iteration. Story selection is based upon the stories that will provide the most business value and the estimate of development effort provided by the team.
Product Backlog
The product backlog is a high-level document for the entire project. It contains product backlog items: broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It contains rough estimates, of both business value and development effort.
Product Owner
The Product Owner is a Scrum role that represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, and then places them in the Product Backlog.
A release is a deployable software package that is culmination of one or more iterations of development.
Release Plan
A release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.
An agile method proposed by Ken Schwaber and Jeff Sutherland. Scrum is an agile, lightweight process that can be used to manage and control software and product development. Wrapping existing engineering practices, including XP, Scrum generates the benefits of agile development with the advantages of a simple implementation.
Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended.
“Sprint” is the Scrum term for “iteration,” a time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.
Sprint Backlog
The sprint backlog contains information about how the team is going to implement the requirements for the upcoming sprint. User stories represent what the customer/user wants, and Tasks are used to break stories into actions focused on how to deliver each story.
Sprint Planning Meeting
A Sprint Planning Meeting is used to develop a common understanding of the desired work plan at the beginning of an iteration. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity.
Sprint Review Meeting
At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the Sprint. The second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster.
A spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The goal of a spike is to gain enough knowledge to understand if/how a user story may be delivered. The output of a spike story is an estimate for the original story.
A stand-up is a daily progress meeting, traditionally held within a development area. Business customers may attend for the purpose of gathering information. The term “standup” is derived from the way it is run all attendees must remain standing to keep it short and the team engaged. (Called a Daily Scrum in Scrum.)
Story / User Story
A story is a particular business need assigned to the software development team. Stories must be broken down into small enough components that they may be delivered in a single development iteration.
The team has the responsibility to deliver the product. A small team of 5-9 people with cross- functional skills (designer, developer, tester, etc.) work together to design, develop, and test user stories in the iteration backlog.
A timebox is a defined period of time during which a story or task must be accomplished. Timeboxes are commonly used in agile software development to manage software development risk. Development teams are repeatedly tasked with producing a releasable improvement to software, timeboxed to a specific number of weeks.
Velocity is the number of story points used as a guide for planning the next iteration of a development project. Velocity is based on measurements taken during previous iteration cycles. Velocity is calculated by averaging the original point estimates of the stories that were successfully delivered in the previous 3-5 iterations.

Here are links to some other examples of Agile glossaries:

Looking for guidance in your Agile Transformation? For nearly 3 decades, our experienced coaches have mentored clients in their digital transformations.

Written by Ed Barber


Ed is a Trainer, Coach, Mentor, and Agile Transformation Leader with over 40 years of IT experience. He has performed many roles, from Developer/Tester to Project Manager on projects of all sizes in telecom and has been involved in Agile Transformations at multiple companies in retail, telecom, finance, insurance, and oil/gas domains for over 20 years. Ed is team-focused and likes to facilitate discussions with the right people to resolve problems, applying his experience and the Agile/SAFe principles to discover a solution. Ed has been an SPC since 2012 and has helped launch many Agile Release Trains for various companies.