Requirements Are Breadcrumbs: So Watch Out for Birds [BALife 2025]

To pretend Hansel & Gretel is a project, we are going to focus on the part of the story that is repeated — when Hansel and Gretel are abandoned in the forest. That happens twice. They have a different approach each time and very different results: two attempts we can discuss and learn from.

Or, in project terms:

• Team members: Hansel and Gretel
• Current (undesirable) state: they’re stuck in a forest without food or shelter
• Desired future state: to be home with dad (a questionable choice, but whatever)
• Stakeholders: dad and stepmom
• Project risks: starving, birds, witches, and stepmoms

Or, if we use one of my favourite tools, an opportunity canvas (created by the very excellent Jeff Patton), then it might look like this:

Hansel and Gretel did this project twice, so let’s compare their attempts:

In their first attempt, the team (mainly Hansel) prepared adequately. He thought about what to do, he collected pebbles, and he executed the plan during the abandonment. It works — Hansel and Gretel are able to make it home largely without incident. I call that project a success.

The second attempt is a bit less clear cut. The team (again mostly Hansel) skimps on prep. There are alternative reasons given for this in different re-tellings. In some, the stepmom locks the door so that Hansel is unable to collect pebbles — not dissimilar to how some project sponsors expect delivery to start immediately — but either way, not enough prep.

So they improvise a solution on the fly and drop breadcrumbs from their lunch in an attempt to have something to follow home.

Except: birds happen. Birds eat all the breadcrumbs and they have nothing to follow home. Their plan totally fails and they only make it home after a wildly lucky but ultimately murderous encounter with a witch, all of which (witch?) is quite improbable.

But — despite all that — the project is even more successful than the earlier attempt as they’re now home, rich, and their stepmom is dead. Go figure.

All in all, the second attempt is weirdly successful-ish.

In short, their first attempt was successful because they were able to implement a plan that was robust enough to minimise their key risks, namely, birds. While their second attempt, even if it all worked out in the end, was a failure because they didn’t do so.

Now, if I were a management consultant, I’d create a fancy 2x2 matrix, give it a great name, trademark it, and reduce this lesson down to a simple decision point. Except this shit isn’t simple. Doing requirements well is surprisingly complicated, and to abstract away the complexity won’t do you, or your clients, any favours.

So I won’t. Instead, let’s dive into the complexity.

Like pebbles and breadcrumbs, requirements come in all shapes and sizes.

When I first started out, I worked on a remarkably agile software development team. We used actual physical sticky notes as our requirements documentation. Each had a user story, some scribbled notes, and occasionally a dot if it was blocked for some reason. At the end of the sprint we’d literally bin them — straight into the trash bin that sat at the end of the whiteboard for that purpose.

Nowadays the idea of a sticky note being the actual, for-real requirement record is very rare. Most of us think of requirements as the things we load into Jira or similar systems — with hierarchy, tasks, user stories, titles, IDs, attached Figma files, process maps, and comments.

Much, much more rigorous than the sticky note approach.

And yet not the most rigorous option. At the extreme end of the spectrum are comprehensive product requirements documents (PRDs) and business requirements documents (BRDs). These behemoths contain not just requirements, but all the necessary information around them — context diagrams, use cases, glossaries, and end-to-end views of what a system needs to do.

You can put down BRD, go on a sabbatical for a year, and on your return you could pick it right back up where you left off. It’s the permanent — less flexible — requirements option.

Amusingly, this spectrum of requirements looks remarkably like our Hansel and Gretel metaphor:

• sticky notes = breadcrumbs (temporary, disposable, changeable)
• Jira tickets = pebbles (singular, somewhat persistent, part of a bigger picture)
• BRDs/PRDs = GPS systems (precise, complete, end-to-end, hard to update)

Hansel was constrained by what he could fit in his pockets, but we business analysts are far less constrained. You can add an incredible amount to Jira tickets. Over time, what we think of as requirements has steadily gotten larger and larger. What started as a need statement and maybe some acceptance criteria has morphed into an unrecognisable beast with process maps, user stories, scope definitions, wireframes, UI designs, data models, solution notes, assumptions, dependencies, comments, priorities, histories, user research, testing notes … the list goes on.

Sometimes it feels as if we’ve lost sight of what requirements are meant to achieve. Each element we add to a requirement should have to justify its existence. Are we adding it because it helps the team get home? Or because we think that’s what business analysts are supposed to do?

But, on the other hand, the variety in requirements does make sense because environments also vary dramatically — from small organisations maintaining a single internal app to massive enterprises juggling multiple ERP systems. And what they need to be able to get home also varies.

Which brings us to a sort of obvious truth: we should match our requirements to the terrain we’re in. And the reason is obvious — you don’t want to be the reason your team gets lost in the forest and finds itself at risk of being eaten by a witch!

Sounds easy, right? But how do you actually do that?

The answer isn’t to focus on your requirements — it’s to focus on your environment. So … what birds are circling overhead?

Let’s roll with the metaphor for a while. There are four birds that you should watch out for. These aren’t the only birds you’ll find in the wild, but some of the larger, more common ones.

1. Complexity: Not just technical complexity, but process complexity, regulatory complexity, and integration complexity are all risks. How many moving parts are you dealing with? Are you handling PII data? Working in a regulated environment? Dealing with multiple vendors?
2. Misalignment: How aligned are your stakeholders? Do they agree on what they want, or are they pulling in different directions? Will your requirements document end up being the decision record that gets challenged later?
3. Delays: Requirements and decisions degrade over time. How long will there be between analysis and delivery? I’ve worked on projects where we delivered what we discussed the following week, and on others where requirements won’t be delivered for 2+ years. Or if you’re working on an RFP and dealing with a long procurement process ... there are going to be delays. That’s risk (but one that frequently gets missed).
4. Immaturity: How experienced is your delivery team? Smart senior developers might need minimal guidance, while junior ones require more detail. Are you working with a vendor who’s assigned fresh graduates with no understanding of your business context?

Or in table format:

You might be high risk in some areas, but low risk in others. This stuff is complicated and I don’t want to pretend otherwise. But in any event, our first job is to work out which birds we’re dealing with. And while you mull which birds you should be especially worried about on your current project, let me get on my soapbox for just a moment.

It’s not just about risks — stakes matter, too. The consequences of failure can range from minimal to catastrophic. For Hansel and Gretel, the story would be quite different if the worst that could happen is that they have to call an aunt to come rescue them. If that were the case, their situation might be high risk, but low stakes. Probably not fairy-tale-worthy, to be honest.

But rather than a brief forest adventure culminating with a cup of soup at auntie’s house, the stakes for Hansel and Gretel are starving or becoming a witch’s dinner. Seriously high stakes!

The takeaway from all of this is: the more birds — and the scarier the birds — the more rigour you need. Understanding both risks AND stakes gives you the full picture. A small risk with massive stakes might need more attention than a larger risk with minimal consequences.

Getting requirements right is a balancing act. While Hansel & Gretel tells us what happens if we don’t have enough rigour and try to make our way home using just breadcrumbs, the story lacks a third attempt that helps to illustrate what would happen if they were carrying too much. But we can guess:

• Too little detail: The team gets lost in the forest (the breadcrumb scenario).
• Too much detail: The team gets bogged down with unnecessary weight (like carrying rocks instead of pebbles).
• Just right: The team has enough guidance without carrying excess baggage (i.e., just the right number of pebbles).

What’s interesting about the too-much-detail scenario is that it isn’t just that it is weighing the team down, it actually represents unnecessary effort from you. The more you add, the more work you have to put in, and the less time you have to do other things. There’s an opportunity cost to everything you add. This makes it even more important that every element you add to your requirements must justify itself.

The key is to use only the ingredients necessary for your specific terrain. You should do the least you can get away with, not the most!

Anything that doesn’t directly contribute to delivering the outcome is waste. Specifically: your wasted effort.

Yip. Super grim. Job markets are utterly pants. Where a few years ago you could easily bounce from contract to contract and be rolling in fun projects and challenging problems, now we have hundreds of applicants for any single BA role. And getting a foot in the door is even harder.

Simply being good at your job isn’t enough anymore — you need to be seen to be good, be seen to focus on the right things, and be seen to deliver outcomes.

The problem is that we often assume that people understand what we do as business analysts. They don’t. You need to make your value visible. If you focus solely on digging into details, you’re missing the opportunity to add value visibly.

It is grim. But there is also opportunity here. Opportunity to position yourself as the person who helps get the team home. As the person who is pulling the plan together. As the Hansel in the room.

And the simplest way to start is by engaging and collaborating with your teammates.

This is actually why I love collaborative methods for requirements elicitation and documentation, such as story mapping (another Jeff Patton technique). It is such a powerful method because it combines the rigorous structure that you’d more likely find in big PRD/BRDs with the speed of far more temporary methods (like jobs-to-be-done and sticky notes). And more than that, they:

1. Enable real-time feedback on the level of detail needed.
2. Distribute ownership of requirements (no more single point of blame for something missed).
3. Take everyone — team mates and stakeholders alike — on the journey.

When using story mapping or similar collaborative techniques, you can make your work and progress visible. People won’t ever voluntarily go into Jira to check your backlog, but they do love a good Miro board or wall of sticky notes. Perhaps because it feels designery and fun. Look at all the work! Aren’t we all so smart!

And I believe that when I break down a system using story mapping, I end up with a solution that’s more complete and better able to withstand challenges than a PRD—precisely because of the collaborative structure. Many brains really are better than one.

Of course, story mapping is just an example — any facilitated and collaborative workshop approach can achieve similar results. The key is that it’s visible, facilitated, and engaging. Teams don’t want to be walked through a Jira backlog item by item; they want to help to shape the solution. So, why not put them to work?

The funny part about all of this is how attached we are to whatever-the-established-requirements-approach-is-where-we-are. We usually have far more influence over our approach to requirements than we might think — because no one other than us usually cares.

Instead, they care about outcomes.

They care about getting the team home. That’s what you need to be focused on, too. That’s what actually matters. You need to engineer that outcome.

And it’s often way more under your control than you’d think.