Speaking a Common Language in Agile

Speaking a Common Language in Agile

In the various agile classes that I teach, I've found most of the students have learned terminology dependent on the agile methodology their organization uses as well as the tools they use, the corporation they work for, their business domain and various other factors.

Often, corporations will adapt a methodology to their needs and create their own custom way of doing things. But all this adaptation can create some confusion when it comes to talking about, writing, teaching and learning agile. It would be nice if the industry could standardize a few things.

First, Do We Capitalize the ‘A’ in Agile?

Let’s take a very simple thing that shouldn’t really matter, but as someone who has written for various industry publications, primarily about agile methodologies, it matters to me: Do we capitalize the letter “A” in “Agile?”

There are various opinions (believe me, I’ve listened to hours of discussion over this) about capitalizing it when it’s used as a noun, but not as an adjective, always capitalizing, never capitalizing or capitalizing when it describes “mindset,” but not when it is used as an umbrella term for various methodologies. [Editor’s note: We lowercase “agile” here at Front Row Agile, but find the discussions fascinating.]

And if there’s this much debate about when to capitalize the word agile, you can’t imagine the debates about what the word actually means in the context of software development! It seems like in almost every class I teach, there’s at least someone who says something like, “We’re supposedly using ‘agile’ [in air quotes, of course], but we’re doing it all wrong.”

Understanding the ‘Why’ Behind the Rules

Whenever someone says this, I ask more about what they feel the organization is doing wrong. They might say something like, “We only have stand-up meetings every three days for an hour instead of daily for fifteen minutes.”

If the answer is something like this, then I realize that they’re talking about Scrum rather than agile, and they think the problem is that the organization is not following the right rules. We might take this back to the agile principle about the business and developers communicating daily and find out whether it causes a problem to communicate 3 days a week for an hour rather than 5 days a week for 15 minutes.

If it doesn’t cause a problem, then there’s no need to change it, just because there’s a “rule.” If it does cause a problem, then the team needs to inspect and adapt. But, just because a team doesn’t follow all the Scrum rules, does not mean they aren’t agile.

Terminology of Product Backlog Groupings

But I’m digressing from my original message: Lack of standardization of industry terms used in agile methodologies is adding more confusion to an already confusing, and sometimes, hotly debated topic.

My pet peeve? Terms used for items on the product backlog. The Scrum Guide refers to these generically as “product backlog items” or “PBIs” which is an easy way to avoid debate about whether they are capabilities, themes, features, epics, user stories or some other word floating around out there in agile literature.

There seems to be common agreement that user stories are of a size that they can be completed in an iteration (also called sprint), should provide business value and should be sized using story points.

One level lower than a user story is commonly called a task. But when you want to group a bunch of user stories together, well, it might be called an epic or a feature or maybe something else, depending on the tool or methodology.

Another area that can cause huge debate is the definition of “program” versus “project” versus “subproject.”

In the end, it doesn’t really matter what you call it, as long as you all understand what you’re talking about. In my opinion, it’s best to avoid saying something is “right” or “wrong” when it comes to definitions of agile terms.

Just like it’s important to understand the “why” behind a rule rather than just blindly following it, it’s more important to understand the “what” behind a term if it seems like there’s miscommunication.

Before deciding your team is doing agile “wrong,” make sure you’re all speaking a common language. Then work together to figure out what issues there are, and how you might improve.

You can call that plan-do-check-act, a retrospective, inspect and adapt, continuous improvement or agile. Or you could avoid all the buzzwords and just call it good old-fashioned common sense. 


Yvette Francino has more than 30 years in the software development industry, and is an independent consultant, experienced agile leader, coach, author and trainer in various methodologies including SAFe, Scrum, Kanban and large-scale custom methodologies.

Learn More
comments powered by Disqus