A Tour of Basic Agile Terminology


Photo by Olga Guryanova on Unsplash
8 July 2019

Agile concepts often feel quite alien to teams who are used to traditional ways of working, especially when they’re involved in a wholesale, large scale “agile transformation” effort. As John Cutler points out, agile makes no sense! 😁 While it’s best to avoid jargon altogether, there are some basic terms that are useful to know and today I remembered how important it is to introduce teams to those terms and not to assume anyone already knows what they mean, so I’ve written this short guide. You might also enjoy reading my introduction to basic project management terms.

Without being exhaustive, this guide aims to be as basic and straight forward as possible. Let me know what I’ve missed!

Origins of Agile

In 1986 Hirotaka Takeuchi (a Harvard Business School professor) and Ikujiro Nonaka (professor emeritus at Hitotsubashi University in Tokyo) wrote an article in the Harvard Business Review called The New New Product Development Game. They described how the old ways of developing new products didn’t allow companies to be competitive in the new landscape:

The traditional sequential or “relay race” approach to product development...may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.

They go on to describe a “scrum” process which included:

  1. Built-in instability
  2. Self organising project teams
  3. Overlapping development phases
  4. “Multilearning”
  5. Subtle control
  6. Organisational transfer of learning

Years later, in February of 2001, seventeen veterans of the software industry from areas such as Extreme Programming, DSDM and other emerging development methodologies came together in Snowmass Utah to (among other things) talk about an alternative to documentation and process heavy, software development. Read the full story here. What emerged was a concise agile manifesto (which reads almost like haiku):

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

They also wrote a set of 12 principles of agile software development which have come to guide much of software development over the past nearly 20 years.

Common terms

If you’re starting out with agile you’ll hear many of these terms quite frequently:

  • Agile frameworks:
    • Scrum
    • Kanban
    • Scrumban
  • Agile ceremonies:
    • Backlog refinement
    • Sprint planning
    • Daily Stand-up
    • Sprint Review (Demo)
    • Retrospective
  • Agile concepts & roles:
    • Product owner
    • Cross-functional team
    • Kaizen
  • Agile Artefacts:
    • Backlog
    • User Stories
    • Epics
    • Information radiators
    • Acceptance Criteria
    • Definition of Done

Basic agile frameworks

The two basic agile frameworks that many teams adopt (which can be mixed together) are Scrum and Kanban.

Scrum is about committing to doing a specific chunk of work in a given time period called a Sprint. Sprints are often often two weeks but the duration is up to the team. Think about the notion of a rugby scrum where the whole team is involved in a single clear goal within a fixed timeframe.

Kanban, by contrast, is about maximising the continuous flow of work through the system on a perpetual basis. It’s great for BAU and work which can’t be easily planned when new work must be continuously added to the system.

Let’s look deeper.

In both cases, a product owner maintains a product backlog which is a ranked list of user stories (various user needs & desires framed from the user’s perspective). User stories may have specific acceptance criteria which describes how the Product Owner will determine that this ticket is done, but doesn’t define how the team should do the actual work. (e.g. “I can book a flight in fewer than 20 clicks.”) Teams should also consider a “Definition of Done” which defines the requirements for any story to be considered complete (e.g. is it “Live in production” or “Ready to go live” or just “Ready for UAT”?). Similarly, a team’s “Definition of Ready” determines what things must be true for any story to be considered “ready to do”. For example, did the designer and developer review it and agree an approach? Has the team estimated how large or complex it is? Has some high-level analysis been completed?

The user story is the smallest unit of work which independently delivers value. The I.N.V.E.S.T. mnemonic is useful for remembering that stories should be Individual (not dependent on other stories to deliver value), Negotiable (there should be some wiggle room in the story; it’s not a contract), Valuable (if it doesn’t deliver value to stakeholders, don’t do it), Estimatable (if you can’t estimate how big/complex it is, it’s probably too vague), Small/Sized appropriately (if a story is too big, it can be impossible to plan/prioritise/deliver), Testable (if you can’t test the story, it’s too vague or not written correctly).

A larger story which may take several weeks or months to implement is sometimes called an epic. It may be broken into smaller user stories which can be delivered in a few days.

An agile team should be cross-functional meaning that they have complimentary skills and mutual accountability to each other. It means the team has all the skills necessary to design, build, test, deploy, and support a solution which provides real value to the end-user without having to go outside the team.

Scrum

In scrum, the team commits to what they will do in the sprint in a sprint planning session (involving the whole team). It’s great for building new products when the business can let the team focus on delivering a specific set of user stories for a couple of weeks at a time without changing the priorities for the sprint. A team might adopt a “Sprint goal” which is a short sentence describing what they want to achieve in that sprint. It helps to keep the team focused on the most important outcome even as they work on various individual stories. For example, the team might select a sprint goal to “get the authentication system working” or “prove that our disaster recovery strategy will work”. It may be that not every story in the sprint helps to deliver the goal, but the goal should still be met at the end of the sprint to consider it a success.

Usually every morning, the team has a short (15min maximum) check-in with each other called the daily stand-up which is often done standing up near some type of board, screen or other information radiator where they can visualise their work in progress (or WIP). At the standup, each team member will share what they’ve done yesterday, what they’re committing to doing today, and where they need help from their teammates or the delivery manager (sometimes called a Scrum master or Agile master) to liaise with someone outside the team to remove a blocker. It’s like a tiny planning and retrospective session covering the previous and current days.

Teams may also update a burn down chart every day to show how much work has been completed and how much remains in the current sprint. This helps to see if the team is working at a good pace or if something about the work or workflow needs to be changed. A good burn down should show work being completed at a smooth and continuous rate.

At the end of the sprint, the team conducts a sprint review (hopefully demonstrating working software to any interested parties). This is a chance for the team (sometimes led by the Product Owner) to present what they’ve done to their external stakeholders and celebrate what they’ve done. The audience can be quite broad for a sprint review. Afterwards, they they’ll hold a retrospective just for the team to look at what worked well in the past sprint, and come up with ideas to continually improve their ways of working (e.g. the process they follow to do the work).

To make things even smoother, regularly held pre-planning or backlog refinement sessions help the team to get on the same page and develop a shared understanding around the items at the top of the backlog. They ensure these stories are well-defined (meeting the “definition of ready”) so they can be easily committed for delivery in the next Sprint Planning session.

Kanban

The other major agile framework, kanban, comes from another Japanese word which means “signboard”. The kanban method originated at Toyota where sign cards would be placed near the bottom of a stack of automobile parts (e.g. tires) to indicate the moment where the assembly technicians should request more stock. In this way, they reduced excess inventory build up and ensured parts were always available when needed.

In software development, kanban creates a visible workflow of different states and encourages individuals to “pull” work through the system as they have capacity to prevent unfinished work from building up. The four basic steps of kanban are to:

  1. Visualise the workflow
  2. Limit work in progress
  3. Make policies explicit
  4. Remove waste and maximise flow (using data!)

Read more about getting started with kanban.

Kanban is useful when you can’t predict what’s coming next or when you want to make small incremental improvements rather than big changes in your ways of working.

A kanban board is very useful in showing where work is getting “stuck” so that you can focus on improving those areas and maximising flow.

Many teams using kanban also use daily standups, demos (or reviews) to share what they’ve done, and retrospectives to keep improving.

Teams often combine elements of both in something called Scrumban. In this model, teams may visualise their work and maximise flow (as in kanban) but use the sprint timebox to help define clear goals and measure how much work they can deliver in a given time period.

Estimation & Velocity

Scrum embraces the fact that not all stories are the same size. In this case, a team may estimate the relative size & complexity of a story using T-shirt sizes (S, M, L, XL) or story points. By adding up how many story points were delivered in a sprint, the teams establish their velocity. This number helps teams decide how much to take on in each sprint. Ideally, a team’s velocity is constantly increasing as the team matures.

In kanban, the goal is usually to slice stories so that they are similar in size and complexity. By measuring the time required to go from idea to implementation (known as cycle time or lead time) for many stories (or tickets), teams can get very good at predicting how long (on average) a new piece of work will take. This is easier when the work can be standardised.

Some teams avoid estimating altogether because they believe their work is too variable and the effort required to estimate doesn’t provide enough certainty to justify the cost.

Other teams enjoy estimating because it forces them to really dig into each story and ensure they understand all the nuances of how they will deliver it.

Continuous improvement

The most important thing in adopting agile is to inspect and adapt. You’ll hear this phrase frequently and may also hear Plan, Do, Check, Adjust (or PDCA) as a way to describe the continuous process of doing the work, observing how the work happens, and making changes to improve how the work gets done. You’ll sometimes hear the Japanese word kaizen used to describe this process of continuous improvement.

Conclusion

It can feel daunting in the beginning but as long as you remember to keep talking about ways to improve and keep implementing your ideas and measuring the results, you’ll get better and better. This is the heart of agile.

I hope this guide has been useful. Please get in touch and let me know. Also check out my introduction to basic project management terms.

Tags:  agile