To excel in requirements prioritization, focus on outcomes, not features

Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work: requirements prioritization.

No matter what type of software project you are working on, there’s always more to build than your organization has people, time, or money for. Even in the unlikely case of a project not suffering from resource limitation, typically the more capabilities you add to a project or a software release, the more users will have to wait to start extracting value from the solution. Even with plenty of resources available, a release with more features will normally take longer due to task dependencies, communication overhead caused by an increased number of team members, and so forth.

Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process:

1. Clarify with business stakeholders not only the outcomes they expect, but when these outcomes need to happen.
2. Clarify with the technical stakeholders the technical constraints associated with the project.
3. Slice out a release strategy based on the desired outcomes. Determine which parts of the solution can wait to be implemented later, and which need to be built right away.

Here’s an example to illustrate how you can apply this framework to your next project. Imagine that you’ve been assigned an initiative to enhance an ecommerce platform used by your organization to sell products to consumers. The company has a webstore where customers can add products to an online shopping cart and submit their order, and now it wants to support offering discounts to selected groups of customers.

One option would be to work on all types of promotional discounts identified as important by the business stakeholders at the same time, building functionality for creating coupons granting a discount in shipping charges (up to 100% to cover free shipping), a % or $ discount applicable to the entire order, and a % or $ discount applicable to a specific product or product line.

A better approach, however, will surface when you apply our 3-step approach:

Step 1: Clarify with the business stakeholders not only the outcomes they expect, but when these outcomes need to happen.

By interviewing stakeholders from the business side, you could learn the following:

• For the next 3 months, the expected outcome is to be able to start A/B testing which type of promotion work best between % and $ discount at order level, so the Marketing team can refine their promotional strategy for the rest of the year based on the test results.
• In a horizon of 6 months, the expected outcome is to be able to offer free shipping to consumers that haven’t placed an order in the last 3 months, in an attempt to win them back.
• About 8 months from now, the expected outcome is to be able to use % and $ discount for specific products and product lines to test their popularity among customers.

Step 2: Clarify with the technical stakeholders the technical constraints for the project.

Based on the information from the business side, you can now talk to the technical stakeholders. You might learn that postponing the implementation of the types of discounts that would not be immediately used would indeed speed up the delivery of the high-priority features, without causing any inefficiency as a result of a phased delivery of the additional capabilities.

Step 3: Slice out a release strategy based on the desired outcomes.

Armed with the information from steps 1 and 2, you would be in a position to prioritize the most valuable pieces of functionality to delivered in Release 1, allowing the business and its customers to start benefitting from promotional discounts while the less urgent capabilities were still being built for future releases:

Release 1: Ability to create coupons configured to provide a % or $ discount for an entire order.

• The engineering team would create the back- and front-end functionality to enable coupon creation, with fields for the user to enter the number of coupons to be generated and the $ or % discount to be applied to the order. The order submission logic would be enhanced to accommodate order-level discounts.

Release 2: Ability to create coupons configured to provide free shipping for an entire order.

• The engineering team would expand the back- and front-end functionality to enable a choice, during coupon creation, between % or $ discount and free shipping. Previously built functionality to enter number of coupon codes to be generated and coupon expiration date would now be shared between the two types of promotions. The order submission logic would be enhanced to accommodate free shipping orders.

Release 3: Ability to create coupons configured to provide % or $ discount for specific products or product lines.

• The engineering team would now expand the user interface for coupon creation to accommodate the new benefit of % or $ discount for specific products or product lines. Previously built functionality to enter number of coupon codes to be generated, coupon expiration date, $ or % value for the discount, would be reused, and augmented to support the selection of products or product lines to tie to the coupon codes during coupon creation. The order submission logic would be enhanced to accommodate product-specific discounts.

Granted, not all projects will have such a clear delineation of what parts of the solution can be deferred like in the example above. Still, with a bit of analysis, it’s not too difficult to determine what’s truly required for a “minimum viable feature” that can accelerate the delivery of value to the organization and the end-users. For example, let’s say you’re building a capability that allows employees to bookmark certain pages of an internal application so they can return to these pages more quickly than using the standard navigation menu. After a certain number of bookmarks have been saved, it’s likely that users would want to be able to group bookmarks into categories, to make it easier to find them. They’d also want to delete bookmarks when they are no longer relevant, and so forth. Still, because it’s unlikely that users will have a large number of bookmarks saved or deleted on day one, it might be entirely possible to slice the delivery of the bookmarking functionality as follows:

Release 1: Ability to bookmark pages, and select a bookmark to open the corresponding page.

Release 2: Ability to delete bookmarks.

Release 3: Ability to organize bookmarks into categories (create category, move bookmark into category, rename category).

Release 4: Ability to delete categories of bookmarks, and search bookmarks by keyword.

With a smaller scope for the bookmark functionality, Release 1 would be able to include more enhancements to other parts of the application that can deliver immediate value to users, as opposed to focusing on the full implementation of the bookmarking features, many of which would not be valuable for users until a later time.

The benefits of delivering small slices of functionality that people can actually use, as opposed to requiring users to wait until a full solution is built, is well illustrated by Henrik Kniberg in this drawing also included the recommended book User Story Mapping: Discover the Whole Story, Build the Right Product:

When stakeholders’ expectations are high, timelines are short, and resources are limited, it’s critical to make sure your team is delivering as much value as possible in each software release. By using the proposed 3-step approach, you’ll be able to more easily identify the relative importance of each slice of functionality based on the business outcomes they can provide, and define the best approach to support the delivery of the highest value first.