Trying to work with business agility and adopting a more iterative approach to the way we work is becoming increasingly commonplace these days.
Lots of organisations claim to be working in an agile way, or have agile transformation programs running in an attempt to iterate and release products (often software based) to customers more quickly.
Many attempt this in some guise. Few get it right. But either way, with it comes a crap tonne of new terminology and if we can’t grasp the basics and learn what the words mean, we have little chance of maturing into teams working with full agility.
Even if you’re not part of the development or testing team involved in the transformation, you probably hear the terminology being used by others and it’s annoying and confusing not knowing what people are jabbering about. So whether you’re part of a team starting to work in this way, or have people around you using unfamiliar words, here’s an agile jargon buster to help. (NB this is based on IT software projects using this methodology):
Backlog – a list of stuff that needs to be done in order to deliver the product, or project. In priority order. The stuff is broken down into very small chunks known as…
User stories – written in a standardised format with the focus on the person (user) who benefits from it. Normally looks something like ‘As a (the person benefiting from it)….I want to (the action required)…..So that (the benefit gained). User stories should focus on a small aspect of functionality that can be built and tested end to end within a short time period know as a…
Sprint / Iteration – can be anything from multiple days to several weeks in duration, but the most common is 2 weeks. The team who work on the backlog each Sprint should be a…
Cross-functional team – in that it’s a small group of a mixture of designers, developers, testers, basically whatever resources are needed to complete the user stories. It becomes cross-functional because it’s a small team, and whilst people may have specialist skills, it’s the whole teams responsibility to work together to get stuff done, so knowledge and skills sharing should be common place. This is often achieved by…
Pairing – where 2 members of the team share a computer and keyboard in order to ‘pair up’ together on a user story in order to progress it. For developers this is also known as pair programming. The teams ultimate aim is to become…
Self organising – driven by the idea that the team and the individuals within it become so well organised and well balanced that they are able to choose how best to accomplish their work, rather than being directed by others outside the team. Obviously this takes time. Many sprints of working together to accomplish this state, but it’s in line with one of the key concepts of agile…
Continuous improvement – both from a team perspective and from a code perspective an agile team should always be trying to improve. To reduce waste. To provide quality. To become more efficient. To increase their…
Velocity – the volume of work (user stories) that can be completed within each sprint. All stories should be small enough to complete within a sprint, but some will be more complex than others, which the team will determine based on…
Relative complexity – this is a way for the team to compare different stories based on how simple or difficult they are. The method for documenting how complex each story is known as…
Estimation – where the team come together to discuss and agree what’s required to complete the work and give it a value of…
Story points – typically using the fibonnaci sequence of numbers, where a 1 indicates something very easy to complete and the higher the number the more complex the work. To get everyone to agree on the estimate, the team normally play a game of…
Planning poker – where the team discusses a user story together in detail, asking questions, challenging the scope and acceptance criteria until it is understood week enough for each person to estimate the size of the work. Just like poker, everyone selects a card with the value they believe to be accurate, but keeps it to themselves until everyone is ready, then all the cards are revealed and consensus is hopefully reached. Once a bunch of user stories have estimates on them the team can agree how many of them they are willing to bring into their…
Sprint commitment – over time, using the above techniques a team matures and comes to understand its velocity. It has data from previous sprints velocity that can be used to make informed decisions on what can be achieved in the future. At the start of each sprint the team should collectively agree on the amount of work it is willing to accept into the sprint and to commit to completing. This commitment is made on a best intentions basis, will sometimes be met, at other times will not be met, and sometimes will be exceeded. The person who facilitates the estimation and sprint planning sessions (among others) for the team is the…
Scrum master – there to serve and lead the team. To encourage best practise. To train and coach the team on the chosen methodology. To track progress against the sprint commitment, typically using a…
Burn down chart – a visual representation of the teams velocity. Based on story points completed versus time, it gives an indication of whether the team is likely to meet the commitment or not. It looks something like the below, but the specifics of what happened during the sprint and why will be discussed and reviewed during the…
Retrospective – a pause for the whole team to down tools and take time to look back over the sprint, focussing on what went well that you want to continue to do, and what lessons were learnt or what did not go well that you want avoid happening again. It’s not the only time the team down tools. Each morning there will also be a…
Stand-up – a short meeting to provide the whole team the opportunity to discuss current work, ask questions, highlight blockers, with the main focus being on how to get work done.
Minimum viable product (MVP) – The smallest thing of value you can put in front of customers in order to start to gather feedback and learn. This should be the smallest sub set of user stories from your backlog, that are determined by the…
Product owner – the teams ultimate stakeholder. When it comes to overall scope, they’re the decision maker. They decide what order they want the work completed in. This should should always be based on business / customer value. It’s their job to unsure that the stories (or set of stories) that are the highest priority and provide the most value should be at the top. They should also be on hand for the team at any time, to answer questions. Of course over time, priorities may change, so they also need to ensure they regularly do some…
Backlog grooming – where the backlog is reviewed and redundant stories are removed, new stories are added, or stories are re-ordered.
Methodology – Scrum, Kanban, Lean, XP, LESS are all different frameworks / guidelines for ways of working with agility, however in the true spirit of agility most teams bastardise these and pick what works best for them (and keeps changing and trying new things along the way to try to continuously improve). I’m deliberately focussing on the terminology in this post, so for more info about the framework itself, try this.
WIP limit (work in progress limit) – some teams adopt this model to ensure there is a focus on ‘stop starting and start finishing’ work. It’s where you have more of the team working on a smaller number of stories but actually completing them quicker. This is always preferable to having lots of work in progress, but nothing complete. In terms of what classifies something as complete the team should have collectively defined a…
Definition of done – a clear set of criteria that need to be met in order to agree that a user story has been completed. This is often complimented in sprint planning by ensuring the user stories meet the…
Definition of ready – a clear set of criteria that the user story needs to meet in order to be accepted into a sprint. A key part of this is having well understood…
Acceptance criteria – which defines / describes the specific function or behaviour that the user story is designed to provide. Tests scripts should be based on proving the acceptance criteria is met. If the acceptance criteria is written in a certain format it allows for…
Automated testing – having test scripts being systematicaly run on your code on a regular and ongoing basis means that as soon as something breaks you know about it. Some people even write and automate the tests before completing the code, knowing that the test will fail, but they include in their definition of done that the tests have to pass. When the focus is this way round you will hear the term…
TDD (Test driven development) – start with the end in mind. Write the test first. Then build the code to ensure the test passes. Test automation is particularly important when the team gets to the point of…
Continuous integration – where code is not being merged once per sprint. Not once a week. Not even daily, but several times a day. That’s the dream.
I could go on all day, but I’m getting a bit bored, I’m sure you are too, so let’s call it a day there.
This list is not exhaustive. Not even close, but hopefully it goes some way to improving or refreshing your understanding of the most common terminology people use when discussing agile.
I’m sure I’ve missed some, so feel free to add more to the comments.