Are you facing an abundance of product requirements, all of them “essential”?
Try these suggestions.
A reader wrote to me with questions regarding a development project that he thought involved too many requirements and too little flexibility around requirement priorities. (You’ve never heard of such a thing before, right?) He was concerned about his team’s ability to satisfy those stringent demands. Here are his questions and my responses to him.
His Questions
“I’m working on a project to implement a learning tool. We have 89 requirements in the form of user stories, and all of them are prioritized as ‘must-have.’ The problem is that the tool is not fit for use if the solution doesn’t meet all the requirements. I’m planning on reevaluating the requirements to look for more flexibility. What should I look for to make sure my customers are kept happy?
“Also, I feel that the number of requirements has added to the project’s complexity. Is there really a relationship between the number of requirements and the complexity of a project? If so, how are they related? How would you recommend I go about reducing them? How will I know if I’ve reduced them to a number that still ensures that the tool is fit for purpose?”
My Answers
I offered these suggestions about how the correspondent might address his challenges.
Requirements and Complexity
As a first approximation, the size of the product is roughly proportional to the number of requirements, but size and complexity aren’t the same. You could have a large product that isn’t necessarily complex in the sense that individual requirements are not tightly interrelated and are straightforward to implement. In general, though, the more requirements you have, the bigger the product will be.
Not all requirements are created equal. They might not be written at the same level of granularity. One story might describe a single small piece of functionality, but another could conceal a lot of depth in a short statement. Some stories could be easier to implement than others. Certain requirements may be subject to complex business rules or acceptance criteria, whereas others are not. Some might reflect well-understood capabilities that your team has handled before, while others are novel and hence riskier. So, simply counting your requirements isn’t terribly meaningful.
Keeping Your Customers Happy
Begin by identifying your various customers and other stakeholders. There might be more than you think, and some of them will be more important to satisfy than others. Also, determine the product’s business requirements. That is, what is your company hoping to accomplish by building this learning tool? What are their business objectives?
Having business objectives in hand allows you to check for alignment of your requirements with those objectives. You might discover that certain proposed stories don’t contribute directly to achieving the desired business outcomes. Those stories could perhaps be discarded or deferred to the future. Your goal is to ensure that you’ve accumulated the right set of requirements to know that the solution will provide your customers with sufficient business value.
Use cases or well-crafted user stories (that is, not just a pile of stories that describe random functionality fragments) are a good way to understand what users need to be able to do with the solution. These user requirements should align with the business requirements such that, if they’re satisfied, the product likely will achieve its business objectives. Without clear objectives, you can’t make this assessment. That disconnect can lead to products that are overstuffed with functionality and yet still fail to achieve the desired outcomes.
Prioritizing Requirements
Do you really have to reduce the number of requirements? The problem is however big and complex it is. If you’re building a space station, there will be an awful lot of requirements. A checkbook balancing program won’t have so many requirements.
If you do have business objectives identified, and you’ve determined that the project can’t achieve its objectives unless all 89 user stories are implemented, then clearly you need them all! In many cases, though, it’s not essential to implement all of the desired functionality in the initial release.
Products do require a critical mass of functionality, some core set of capabilities that have to be there on Day One or the users can’t get their jobs done. If a word processor doesn’t contain text editing, formatting, file saving, and printing capabilities, it’s not a word processor yet, and it’s not usable. But once those basic capabilities are in place, you can incrementally enhance the word processor by adding things like spellcheck, revision marks, mail merge, and whatever else you ultimately want to have.
I recommend that you carefully “scrub” the requirements by identifying those that ABSOLUTELY MUST be present in the initial release and those that could wait for later. That’s what requirements prioritization is all about. Look for groups of user stories that the team could implement incrementally over time to grow the product towards its ultimate capabilities. Unfortunately, requirements prioritization activities do often leave far too many as “must-haves.” I focus on the two dimensions of importance and urgency when prioritizing requirements.
One prioritization strategy is to consider whether you have multiple user classes that have different sets of needs. It might be more important from a business perspective to make some of these user classes happier than others. If your 89 user stories represent the full collection of requirements from multiple user classes, perhaps you can defer some of those that came from less important user classes.
Unfortunately, there are no easy answers for these kinds of thorny requirements issues. I can only suggest thought processes to help you work through the problem and focus on what you really need to build to achieve the desired business outcomes.
==============
Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.