What Agile Requirements Taught Me About Communication

Before going through Agile training, the only involvement I’d had with IT departments was that of the typical non-IT employee. I submitted tickets for things that were broken, lost passwords, etc. I would work with the technical people to make something, make something work, or make something work differently, usually website- or CRM-focused. I never really understood what went into the process, or how to truly communicate what I wanted. So I would draw pictures – the only common language we shared.  

Imagine my surprise when I arrive at a new job to learn I’m going to be going through Scrum (“What’s that?”) training to become a Product Owner.

Imagine my added surprise when I realized, three years later, that though I’m no longer using Agile Methodologies at the company I currently work at, I’ve unconsciously applied them to my method of communication.

In Agile requirements gathering, you are taught to write a requirement in a very specific way.

Part 1: "As a ________," Here, you are supposed to define your audience.

“As a consumer…”
“As a stakeholder…”

You are forced to take a step back to let the developer know whom they’re building this for.

Part 2: "…I would like ________ (to happen)…" This is the easy part. This is what we’re all used to communicating.

“…I want similar books to the ones I’ve already read, to be recommended to me on my account….”
“…I want a real-time report that tells me how many sales I’ve made...”

Part 3: "…, so that _______" This is the “why”. This is important so the developer can understand how your requirement will be used. What value does the consumer or stakeholder (or whomever) get out of it this development?

“…so I can easily find books to buy, by new authors in a similar genre.”
“…so I can check regularly to see if I’m on target to meet my sales goals.”

As I mentioned earlier, I hadn’t used any of this in a couple of years. Or so I thought. I caught myself writing a standard e-mail asking for something, where I would normally only communicate Part 2. This time, without even thinking, I’d included the “who” and the “why”.  So I got to thinking about how many times I’d done this without even realizing it. I’ve done it in meetings, when trying to explain something. I’ve turned it around on other people, to better understand what they were asking me for. I believe this has saved me a lot of time in exchanging multiple e-mails or preventing me from starting on a project but having to backtrack because I didn’t fully understand the need.

Little did I know this simple requirements gathering exercise would help me to become a better communicator overall.


By Tonya Cardinali
[email protected]

---