Requirements Prioritization Made Simple

Ask your stakeholders to prioritize requirements and you are likely to hear groans. While conceptually we understand that project budgets are limited, and requirements prioritization helps us receive the most possible value for our investments in technology, there is a part of us that wants it ALL and wants it ALL NOW.

And that’s why we resist requirements prioritization. If you’ve been told you are “too business oriented,” this is an area you want to focus on – helping your stakeholders get clear about their priorities and what is really, truly important.

 

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Today, I want to simplify requirements prioritization. If your experience is anything like mine, when you ask your stakeholders to prioritize their requirements, you just hear groans of “Nooooo. Everything’s important.”

When you think about even asking them to prioritize their requirements, you probably go, “No.” Maybe you feel like everything is important, or maybe you feel like it’s just hard to ask what’s most important from your business stakeholders.

And if you’ve been told that you’re too business oriented – this is feedback that some business analysts receive when they are kind of a doormat for the business – and just say, okay, you want everything. Let me put everything into the requirements.

If you’ve been told that, that you’re too business-oriented, or something along those lines, prioritization is an area that you need to focus on and get clear on and start adding to your toolkit in how you work with your business team.

Let’s talk about some simple and easy ways. This does not have to be complicated.

Requirements Prioritization Get Easier When You Know What Problem You Are Solving

The first thing to know is what problem are you solving? I say this again and again and again. I’ve been saying it a lot in videos lately, but it’s such a critical part. If you don’t know what problem you’re solving, you don’t know what requirements are most important. It’s simple as that. That is the information you need.

If you know that you’re solving XYZ problem and your business objectives are to increase sales or improve retention, or make a specific thing more efficient, then you know what requirements are most important because you can look at what requirements are in surface to that business need.

As we’re implementing our new learning management system, the most critical business problem for us is to streamline the participant instructor interaction and eliminate the manual pieces in between that are slowing the process down.

They’re also making it difficult to scale that process as we serve more customers. Everything that we’re doing is coming up against that problem. Is this feature helping us solve that problem? Very clear filter.

Requirements Prioritization Gets Easier When You Make It Simple

There are a lot of sophisticated tools out there for prioritizing requirements that you can try and experiment with. We focus on practical real-world simple best practices at Bridging the Gap, and so, the two ways I suggest prioritization are either 1, 2, and 3.

So, you give every requirement a 1, 2, or a 3; 1 being high priority, 2 being medium priority, 3 being low priority or a nice-to-have. That is pretty simple. The challenge is that everybody wants everything to be a 1.

You have to go back to what problem are we solving – 1’s are the things that help us solve this problem in the most impactful way, 2’s might be like they could add to the problem, but they’re not essential to solving the problem, and 3’s are related things that we’d like that came up but probably aren’t going to see the light of day in this project. You’re clear, then, on your 1’s, 2’s, and 3’s.

The other idea is to rank order. So, 1, 2, and 3 would be every requirement is a 1, 2, or 3. Rank ordering would be like there is a 1, a 2, a 3, a 4, a 5, a 6, all the way down the list. You’re saying #1 is more important and #2 is more important than #3 and you’re rank ordering the priorities.

That’s a strong way to prioritize that’s used on agile software development teams to rank the product backlog. There’s no ambiguity about what is more important than what. There’s no sense of like there are 20 things that are #1 and we can only do three things in this sprint. What are the three of those 20? “Oh, we’ll do 1, 2, and 3. And then the next sprint we’ll do 4, 5, and 6.”

I find that combining the techniques works well because if you have a product backlog that has 20, 30, 50 items, ranking 1-50 starts to feel like is there much difference between 45 and 46? Does that matter?

While we’re still working on numbers 1, 2, and 3, using 1, 2, and 3 to chunk out that backlog and then ranking the ones that are our 1 priority can be a way to sift through it and not have to rank everything on that backlog, which would get to be a tedious task that’s adding less and less value as you get further down the backlog.

Requirements Prioritization Gets Easier When You Understand Timelines and Costs

The other final tip I want to share with you in terms of making requirements prioritization easier is that it can help to understand the time and the cost involved in implementing that requirement.

How this is coming up for us in the learning management system is I did the 1, 2, 3 and we had some 3’s; we had some things that were non-essential, but if they weren’t there already that would be great. But if we have to do anything to make them happen, not going to happen.

Then the 2’s, the rule that I set out for the 2’s – the 1’s were essential; they were essential to solving the problem, and they were essential to how we deliver the courses and deliver our business. We had to have the 1’s. They were essential in order to release this product to our community.

The 2’s were really good stuff. They weren’t just like, “Oh, it would be nice to have that.” They were good features that were going to add a lot of value to our business. I wanted to make sure that we could keep the scope of the project tight to get it done in the timeline that we had and use the tools that we had, and to manage the budget that we had available.

With 2’s, I said, “If it’s a configuration,” if it’s just a matter of somebody setting something up and configuring it, or maybe less than an hour of work, let’s do it. If a 2 is going to require custom development or a new tool that we don’t have or not available out of the box, we’re not going to talk about it for the scope of this project.

It made it clear what that 2 meant, and it became easier to prioritize as we understood what was the time and cost available. Then we could look at the 2’s that were potentially in scope based on knowing how they could be implemented. It takes a little bit of analysis, a little bit of collaboration with your team to give a gut check on each of those requirements and say, “How much would this take?” “How much would this cost?”

You can find your stakeholder priorities tend to shift a little bit. Sometimes something you thought was important, like a 1, you’re like, “Oh, that’s two weeks of work?” It’s not a 1; maybe it’s more like a 2 or a 3.

And you see people when they understand the time and the scope and the budget that goes into implementing that requirement, then, they start to get more comfortable with the prioritization because it has more meaning. It has an actual value assigned to it that’s not just, “Hey, as long as I can ask for everything, I’m going to ask for everything until you tell me that I have to pick and choose to fit within a budget.”

Requirements Prioritization: Keep It Simple

Those are my three tips. You’re focused on keeping it simple. It doesn’t have to be a complicated process. More than likely, if you’re trying to make it a complicated process, it’s because you don’t understand what problem you’re solving and it’s not clear who is in charge of making decisions for this project.

You’re using a more complicated technique to try to, under the hood, facilitate between the stakeholders who are just not getting together and agreeing, and instead, we should be focusing on those core conversations that they’re having about what problem they’re solving and what the end result of this project needs to be.

And getting a clear direction and clear decision on that, which is going to make our whole project go easier, and going to make prioritization quite apparent once you get into the details and provide people with the information they need to make a good decision.

I’d love to hear how you prioritize requirements, or what challenges come up for you as you do this. It’s simple, conceptually. In the real world is where the fun happens. I’d love to hear what’s coming up for you on this topic.

Again, this is Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

>> Get Your Quick Start to Success as a Business Analyst

At Bridging the Gap, we help mid-career professionals build the foundational business analyst skills they need to thrive in a variety of business analyst roles.

If business analysis is a career that you want to excel at, the absolute best next thing to do is to join my free Quick Start to Success workshop. You’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.

>> Click here to register for the free workshop today <<

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® training program, you’ll gain real world experience in the industry-standard techniques and business analysis processes. You’ll create work samples with the opportunity to have them vetted by experienced instructors.

>> Click here for more information about The Blueprint <<