Do I really have to stand? An agile glossary

As we work with larger and more complex companies, we become the people to introduce Agile ways of working into an organisation. However, when you’ve worked using Agile for a decade or more, as many of us have, you often assume some knowledge that people don’t have. With that in mind, we decided to put together a glossary of Agile terms, so you know why we randomly ask you to stand up every day at the same time! Agile - let’s start with an “easy” one. What is this Agile thing? It’s described as “a set of principles, not a process”. Below you can see a classy business image with this set of principles but really, the clue is in the name. If you want your organisation to be Agile you mean just that, a business that is malleable and responsive to change. Don’t let someone come in and hit you with a process stick in the name of agile.

agilemanifesto

Backlog - This is what we’ll help you to build at the start of the project. Simply put, it is a list of things you want, prioritised from most to least important. Decide something is more important? Move it to the top! Realise that support for cat gifs is not as crucial as you once thought? Move it down, or drop it off the list altogether. As a team, we will work through a backlog from top to bottom, until we get to the end.

Card - a “card” is a unit of work. Each thing you want to be done goes on a card, and each card goes into the backlog. So when you move a card up or down the backlog, you are telling the team how important that piece of work is to you

Continuous Delivery - This is the process of taking the fear out of putting new work live. Rather than having “big bang” releases that are built up over the course of weeks or months, we aim to release new work as soon as it’s ready, often several times a day.

Demo - Where we show off the progress we’ve made. This can as often as the client requires, but is mostly commonly done weekly. This is crucial to keep the stakeholders up to date with progress and allows them to make changes to the backlog in response to the latest work.

Kanban - literally the Japanese word for “visual signal” or “card”. Kanban is a framework originally developed for use in the Toyota factory, and our preferred way of working. It revolves around the flow of work through a system, rather than trying to predict each piece of work along with a traditional Gantt-style plan.

Kanban board - a physical representation of the work you are currently doing, usually stuck on a wall in the office. This is designed to be an at-a-glance view of what each team member is doing at any given moment, and is also where the morning status meeting (a stand-up) is held.

Little’s Law - Maths! Little’s Law is the maths behind Kanban, and the formula we use when showing overall progress and forecasting timelines for the future. Little’s Law uses a combination of Throughput (the number of work items completed in a pre-defined period), Lead Time (the average time it takes to complete a work item) and Work In Progress (the average number of work items in progress at any one time).

Product Owner - This one definitely needs more than a short entry. The role of Product Owner is one of the roles most likely to be misinterpreted within an agile team, and it is far more complex than it is given credit for, which is why a team also finds itself with a part-time Product Owner when full-time attention is needed.  For more on this, I suggest checking out Toqir's blog on good Product Ownership

Retrospective - The best teams learn from their mistakes, so it’s important to have time to call mistakes out, and discuss how you can improve as a result. This is where we use retrospectives (often shortened to just “retro”), where the whole team gets together (usually once a month,but can be at any time) and discusses where things have worked, and where they haven’t.

Scrum - Another framework for running a project, and the one that people will probably most readily recognise when talking about Agile. This method revolves around story points and "sprint" cycles of around two weeks. However, at Red Badger we definitely prefer to use Kanban.

Standup - A morning status meeting. Called “standup” because the aim is to literally stand in a circle around the project Kanban board. Each team member reports what they did the previous day, what they are planning to do today, and whether they have anything blocking them from completing a task. It is ideally timeboxed to 15 minutes or less to avoid unneeded disruption

User Story - Each card should represent a piece of value for the end user. If it doesn’t then it shouldn’t exist. The way that we validate this is by using User Stories. This is a description on each card that follows an easy to remember format. A user story should look like this:

As a someone
I want something
So that something happens for the user

So, going back to the aforementioned cat gif example, the user story would be:

As a user
I want to see cat gifs
So that I feel happier whilst looking at the website

If you cannot figure out a user story for a card, then you should be questioning the value of that piece of work.

This list is by no means exhaustive, and at least some of it could be seen as subjective. However, it should fill some gaps in knowledge for people who are entirely new to agile.