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

Featured
14121 Views
3 Comments
9 Likes

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.


Author: Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook Measuring the Performance of Business Analysts, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her next ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, will be called Tested Stakeholder Interviewing Methods for Business Analysts.

Like this article:
  9 members liked this article
Featured
14121 Views
3 Comments
9 Likes

COMMENTS

adrianab posted on Tuesday, January 26, 2016 10:31 AM
Adding a note here so I get notified when someone leaves a comment. It's always good to hear from readers!
ptsai posted on Thursday, February 11, 2016 6:36 PM
I'd like to suggest that the requirements to be re-prioritised after step 2. The reason being that the technical release is often full for the next 6-12 months like the company I used to work for. The business capabilities often depending on how soon the IT changes can be scheduled into the release schedule. In the complex environment where you've got 10-15 implementation going in parallel often the less important capabilities in your current project may be already in earlier releases due to other projects. It is also in IT driven company culture like the company I have worked before the business stakeholders will reprioritise themselves and adjust their product roadmap accordingly.
adrianab posted on Thursday, February 11, 2016 8:34 PM
Hi, ptsai,

I'm not sure I understand your point. In the model I described (which I am not saying is applicable to all types of situations, as no model is), the requirements haven't yet been prioritized yet by step 2, so there is no reason to "reprioritize after step 2".

Perhaps the disconnect here is because you're talking about a different context. The 3-step approach in the article is being used to prioritize requirements for a single project that has been approved and has its own team and funding. The idea is to maximize time-to-value by prioritizing the capabilities to be delivered according to their contribution to the desired outcomes and when those outcomes become relevant for the business.

In the situation you describe, it looks like the prioritization problem is at the project portfolio level: given a number of projects competing for resources, how do you make sure scarce resources are allocated to the pieces that will deliver the most value for the company as a whole? In that case, yes, to maximize the overall value you would need to focus on slicing out a release strategy that goes across multiple projects and workstreams.

Thanks for taking the time to add to the conversation!


Only registered users may post comments.




Latest Articles






Copyright 2006-2019 by Modern Analyst Media LLC