Stories vs Requirements

I'm here to talk about a business problem I keep seeing. People end up in massive distress, massive fights, massive arguments, or just frustrating discussions about this concept of requirements. Requirements are critical to many players on a contract. Contracts officers, project managers, and analysts want to understand the deep requirements, and they are important. The problem arises when requirements become front-and-center, acting as "THE" only tool to manage a project. That's the reason why I advocate and tell all my clients to go with an agile method which doesn't use rigid requirements—at least not as a front-facing, in-your-face kind of thing. Because here's a problem with requirements: they are basically these weird things that everybody on the analyst and project manager side wants to treat as a black-and-white checkbox that says, "Yes. That requirement was met."

The difficulty comes in breaking down a massive amount of information, which in the operational space has a lot going on. There are far too many moving pieces to rely just on requirements. Requirements are important when you're dealing with a public safety broadband network radio and you want to make sure that things are connected. When it comes down to using an application to share information from the field back to an operations center, requirements are there. They're in the background, but really, it's the operational story that matters, and stories are actually the core of the agile concept.

Stories are incredibly powerful. Neuroscience has taught us that as we listen to a story, our minds actually enter into it. A story can be about something I don't even fully understand, but my brain will put itself into that position and become part of it. It's also how we learn. We have always been a storytelling culture. In operations, stories are utilized extensively. There are lessons learned and after-action reviews. There are stories told during training and exercises, as stories are how we communicate a wealth of information.

So, stories are how we talk to each other. When operators talk to each other about what happened, what they would like to see, or what they would like to change, they tell stories. From that, a good analyst can take and derive meaning. They generate requirements from the stories. They can validate requirements from the stories. The problem occurs when requirements become front-and-centered. You know how to deal with requirements, but they don't mean anything when senior leaders are involved. Senior leaders want to understand things from a policy perspective: What is this project going to do for them? What do they need to do for it? When it comes to policy, you look at where we are today, where we are going, where we will be tomorrow, and what that future state ought to be. On the road to that future state, there is probably a story that says there are going to be policy barriers. They are already there or they are coming, and we need to say, "Sir, Ma'am, we need you to stand up, fight for the project, get in front of that train, and make sure it doesn't hit us." That story is so critical because they need to go out and block things before policy comes into place, or governance needs to be changed. You do that through stories. You explain to them what will happen if it doesn't happen, and then how the future could look given the trajectory of the story of the project we're working on.

The operators, again, are telling stories. Where it gets really interesting is when you look at the technical team. Let's take the technical team, who typically are the ones who both want and hate requirements. Because inevitably, no matter how good you think your requirements are when you go to bed, when you go to do a project—whether it's an internal one you're launching or a formal contracting gig—generally speaking (to use a technical term), your requirements suck. The reality is that the people writing requirements don't know the operators well enough. They don't know how the senior leaders operate well enough. They listen. They read through training manuals. They may sit and talk if they're a really rare type of analyst, building other requirements. And even then, things change. Things weren't documented well enough, and inevitably we are going to discover new requirements as we tell the story throughout the project. So you may as well start here, because this is where the magic happens. Your technical team needs the requirements, and they can derive them, but they must derive them from stories.

The stories from the technical team talking to the operators are just as important, if not more important. The operators need to be engaged. If they just read dry requirements, they're gone. Their attention is out of there. If you're an operator, you know what I'm talking about. If you are not interested, if it is not relevant, your mind moves on to something else. You may be physically sitting there, but you are gone. The technical team must tell a story in "operator speak." There are technical pieces behind it, but they need to translate it and tell a coherent story that we all understand to get on the same page. Then, your operators can tell the tech team where things are wrong. They tell them a slightly adjusted story: "You missed this point. You need to do it this way, because we don't do it that way. We can't do it that way, and here's why." Those conversations aren't rigid requirements; they are stories.

What I want to get across is that it's all about the stories. Requirements are important, but if you're not telling stories, you're going to be in trouble. Hopefully, that helps. I'm Darryl O'Donnell from Technology OPS.

Are you tired of managing rigid requirements and missing the real story? Agile is about human connection and understanding the operational narrative. Sanplex empowers your team to capture both—translating compelling user stories into actionable tasks. From our Free version to our Enterprise edition, Sanplex gives your technical team and operators a shared space to tell the same story. Start building better narratives with Sanplex today.