Mark Llewellyn, Director of Technology at Osmosys Software Solutions in London asks, "How can you be sure you've captured all the requirements?"

Traditional approaches, like Microsoft Dynamics Sure Step, pretend that we can capture all the requirements upfront at the start of a project before we've started development.

Upfront requirements analysis doesn't work. 

You can't capture requirements by writing them down, and you shouldn't try to uncover requirements before your users know something about Power Apps or Dynamics 365 and your developers know something about your users.

Story mapping is an alternative method to help you capture more of your requirements. 

But you'll never capture them all. So don't try too hard, Mark.

Transcription

When you're building a Microsoft business application, how can you be sure you've captured all the requirements?

Welcome to the Amazing Apps show for Microsoft Business Applications builders who want to create amazing business applications that everyone will love.

I am your host, Microsoft Business Applications MVP, Neil Benson. My goal on this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power Apps platform applications.

The question in this episode comes from Mark Llewellyn, director of technology at Osmosys Software Solutions [00:01:00] in the U.K. Thanks for your question, Mark. Mark sent this question in by email. I'm going to get some help reading it out. Alexa, read Mark's question, please.

Hi, Neil. My number one question is, can you be sure you have captured all of the requirements. Regards, Mark L?

Well, it's a great question, Mark.

One of the big differences between an agile approach, like Scrum, and a traditional approach, like SureStep, is that Scrum doesn't pretend that it's possible to uncover and analyse all your requirements upfront before you start building your application. If you're used to a traditional approach, you'll have an analysis phase where you spend several weeks or months in requirements workshops, staring at a blank whiteboard or looking at an out-of-the-box Dynamics 365 application and asking users what on earth it is they want or need. Your business analysts are going to write all that down, documenting everything in a requirement specification that they hope is [00:02:00] complete so that an architect can design the application and estimate everything based on whatever it is the business analyst has heard, interpreted and written down.

I spent 10 years as a business analyst on a mission to write the perfect requirement specification. And I found it was impossible.

Two main reasons for that.

For one, I think we are incapable of faithfully, accurately and unambiguously expressing complex software requirements. Using natural language diagrams and wireframes can help. But what really helps is bringing users and developers together in a discussion so that they can reach a shared understanding that you just will never be able to get from reading a document that somebody else has written based on something that they think they've heard the user say. Then don't try and build all of it. You build a little bit of it, show it to the users and ask for their feedback. It's called empiricism, where we learn from our experience.

The second reason that upfront analysis fails is that [00:03:00] it's done at the what I call the point of 'peak ignorance'. At the beginning of your project, the users know least about Power Apps or Dynamics 365. They might have seen a demo for an hour, but they've never used it in their jobs. And your developers are probably little or no experience working with those users in this organisation, maybe even in this industry. So the longer you can defer uncovering and specifying the requirements, the more knowledgeable your users will be about the application and the more experience your developers will be working with those users.

So those are the two main reasons why I think that trying to uncover and specify all the requirements upfront is futile, but it's still really tempting. And I think the reason that it's tempting is because you've been asked how much is it going to cost and how long is it going to take to build your application. And the only way to answer that is to know what it is you've got to build.

In Scrum, the product owner is the person responsible for maximising the value of the business application, [00:04:00] and it's her responsibility to manage the product backlog and ensure the developers are building the right product. She controls the scope.

There is a tool at product owner you can use at the start of a project to ensure that the initial product backlog contains all the requirements so that the developers can estimate them and answer those two magic questions: how much and how long.

That tool is called a user story map. And it's a two-dimensional visualisation of your product backlog. Down the story map, your requirements are listed in priority order with the most valuable requirements at the top. Across the story map in a horizontal direction, you arranged the requirements by stakeholder. That could be all the different departments, or teams, or user persona that will be using the application or that have an interest in it.

Mark, as long as you do a decent job uncovering all your applications, stakeholders and their most important requirements, it can be fairly sure that you've captured all the requirements.

One [00:05:00] thing to bear in mind, though, it's impossible to capture all the requirements, whether you use a traditional approach or an agile approach. As long as your application exists, someone will want to change it. New requirements will emerge whether or not you have any budget to address those requirements until your application is finally someday retired from production.

You'll find show notes, including a transcript for this episode at Customery.com/010. If you'd like to have your questions about adopting an agile approach to building business applications answered, you can leave a message on the Customery website at Customery.com and clicking on the 'Send voicemail' button on the right-hand side. Include your name, role, where you work and where you live and a short question in your message. Or you can send me a message via LinkedIn and I'll ask Alexa to read a note for you.

Until next time. [00:06:00] Keep sprinting.