When it Comes to Agile Requirements… Procrastinate

Yes. You heard that right.

It is important for us to adopt an Agile mindset, to keep our focus on the values and principles of Agile and not to view it as just another process.

Agile requires us to be flexible as Business Analysts. We don’t produce requirements weeks or months in advance, because requirements change with time. Changing requirements means re-work, which can be a big waste of our time.

Instead, we aim to get them done as close as possible to the date that the team develops the feature.

So, yes, feel free to procrastinate.

But many teams – and many BAs – struggle with this. I frequently discuss agile requirements practice with my students and clients, and one of the most common themes is an expectation from management to have requirements “done” one to four sprints in advance. This expectation isn’t in line with the agile mindset, and BAs ask what can be done about it.

There are many approaches, and here is the one I’ve found to work best.

Gather Understanding, Not Requirements

We need to constantly be meeting and speaking with our customers, but perhaps not for the reason you expect. The goal of customer interactions in Agile needs to be understanding our customers, rather than gathering their requirements.

If you’re working on a CRM system, understand how they handle sales, marketing, and communications today. If you’re working on a website, understand their content management process, who their audience is, and their overall information architecture.

By becoming an expert on the customer, you’ll be much better positioned to create requirements that will work, and you’ll be able to do this more nimbly in the course of a single sprint.

Use Progressive Elaboration

You certainly don’t want to have 500 user stories, complete with 3,500 acceptance criteria and 300 mock-ups ready two months before any of them will be worked on. The task of maintaining all of this would be beyond what a single BA can handle in a typical work week. I’ve written elsewhere that this is a supreme example of waste from the Lean Development world.

Instead, figure out what the 50 epics are – the higher-level functions that represent the core customer needs, and maintain them. Keep those prioritized, and when they rise to the top of the prioritization list, start decomposing them into user stories.

When Challenged, Explain

At some point, a manager will ask why you’re not three to four sprints ahead of the team with requirements. How you respond will make a big difference in how successful you will be on the project.

Tell them this: “We call that [being three to four sprints ahead] ‘Big Requirements Up Front,’ and it just isn’t compatible with our agile process. Requirements change very quickly here, and to keep up with the customer/business need, we need to focus on understanding the big picture in advance and then elaborating the details in a just-in-time fashion.”

Don’t argue. Don’t give them pros and cons. Just state the facts.

Using these three techniques is super effective. And they’ll help you to be agile, which is what we’re all about.

Subscribe