Every field of knowledge has its own jargon, which can be as helpful to insiders (bringing clarity and precision) as it can be irritating to outsiders (bringing obfuscation and exclusion).

Where your field is truly specialist, such jargon may be justified. While a lay person might be confused by a particle physicist’s talk of gluons, anti-particles and wave functions, those words were invented to describe concepts that did not previously exist, and the jargon of quantum mechanics is no more bizarre than the world it tries to describe.

In the more commonplace field of managing software development teams, the underlying concepts are people, their roles, and how they organise themselves and talk to each other, for which vocabulary already exists. When you are trying to improve communications, it’s best to avoid management speak or silly terminology.

The practice of Scrum, the most common Agile methodology, has accumulated a few of these terrible jargon words. The very term ‘Scrum’ itself is an odd one – if you’ve ever talked to a veteran front-rower in a Rugby Union team, they’ll tell you that rugby scrums are a nasty underworld of eye gouging and worse.

But perhaps there’s something in the metaphor of ‘8 people all pushing in the same direction’, so we’ll give that one a pass for now. But there are some truly terrible examples of Scrum jargon that we should really do without. Let’s start with the three worst offenders:

1) Grooming (the Backlog)

This word was bad enough before the Jimmy Savile scandal rocked the UK, but these days it’s even harder to keep a straight face. If you have to do something to the Backlog, prepare it, tidy it, organise it, whatever – don’t groom the damn thing.

2) Impediments

This word abounds in Scrum stand-up meetings, in the 3rd question that every team member is supposed to answer. It’s not a common English word, with a stuffy, old-fashioned feel about it, and is mostly associated with speech impediments. The word ‘blocker’ is preferable, but best of all is to ask ‘do you think you’ll have any problems?’ or ‘will you need any help?’.

3) Pigs & chickens

It’s hard to believe this one ever got any traction. It’s based on a joke – which even if well told is still a lousy joke – about the difference between a pig and a chicken’s involvement in the classic English breakfast of bacon and eggs. The chicken is ‘involved’, while the pig is… wait for it… ‘committed’. Hilarious, huh?

This is then used in the Scrum context to distinguish between core team members who must attend vital meetings and participate in decision-making, and peripheral people whose attendance is not mandatory and might not even be tolerated.

While you might sometimes want to make this distinction, I would advise against doing so using words that are not just utterly confusing, irrelevant, and based on an obscure and humourless joke, they are also downright insulting: ‘chicken’ means coward, and ‘pig’ is an insult in a vast array of cultures and religions. A (very nice) English colleague of mine once referred to his Spanish and Portuguese team-mates as ‘pigs’ with this innocent meaning in mind, but they were genuinely outraged and never forgave him.

While these are the worst offenders, two more terms commonly used within Scrum are worth (dis)honourable mention. It has become so familiar to refer to chunks of work in Scrum teams as Stories that it’s hard to remember how bizarre this term sounds when you first encounter it. Although there is a historical reason for this usage (material for a future article), the fact remains that the everyday meaning of the word ‘Story’ has nothing to do with the world of professional software development, and its usage in this context only adds to confusion.

A closely associated term is the infamous estimation unit known as the Story Point. I’m sure many readers will have experienced the struggle of trying to explain what on earth ‘Story Points’ are to a bewildered senior stakeholder, who cannot understand the relevance of this apparent nonsense to his simple question “when will it be done?”. But Story Points are at least an honest attempt to confront very real difficulties with estimation and forecasting, and it’s not as if these problems disappear when you switch unit.

To finish off, it is worth reflecting that Scrum, at its heart, is a system for organising teams around some meetings and a some documents. At least ‘meetings’ and ‘documents’ are uncontroversial terms in a work setting, right? But somehow in much of the Scrum literature these meetings have been elevated to point where they are known as ceremonies, which you may well this is a somewhat pompous description of a bunch of people having a chat around a table in an office. And the documents that are the input/output of such meetings are themselves known as artifacts (this is actually the word used in the Scrum Guide itself), which suggests that some Scrum advocates might have got a little too emotionally involved in the Indiana Jones series of movies.

All in all, while this article is written somewhat tongue-in-cheek, there is a real price to be paid in the workplace for using terminology that is unclear, silly, vain, or otherwise unfit for purpose. If we want clarity of vision and direction for our teams, a good place to start is to use plain speaking, rather than obfuscation and jargon.