You’ve just joined a team working on a big product. You ask to see the requirements, and your new project manager sends you a spreadsheet with dozens of rows—each representing a requirement. Most of the rows include typical information: the stakeholder, the criteria for meeting the requirement, work estimates, and the MoSCoW (must-be, should-be, could-be, would-be-nice) rating, etc.
The must-be requirements are at the top of the list, but they represent about two-thirds of the requirements. You see that the total work for the must-be requirements almost doubles the capacity of your team, so you ask your product manager how the team will finish everything. “We won’t. We’ll get as much done as we can.”
How do you know which requirements should be done out of all of the ones that must be done? The spreadsheet doesn’t tell you, because it doesn’t document the vision. It represents an aggregation of requirements from multiple stakeholders, presumably trying to achieve multiple goals. “Presumably” is the operative word, because there’s no documentation or traceability from the individual requirements to the goals they are intended to support.
Your product is more likely to fail than to succeed. The Standish Group’s annual CHAOS reports have shown this every single year. Even with an agile team, in 2012, your odds are only two in five that you will succeed. If you have a waterfall team, it’s more like one in seven.
Michel Besner, former CEO of Ryma Technologies wrote about the importance of having a product vision:
When a company is building a new game changer, it’s important to stay focused on the intent and not to get lost on feature creep. Achieving a minimal viable product is very much about choosing the right features while making sure you still are on the right path for your product vision.
When you connect your vision and goals to your requirements, you enable your team to make the best decisions about what to do next and manage the downside of not being able to do everything. It’s this requirements traceability that provides (a) a framework for prioritization, and (b) a context within which to make design and implementation decisions.
As part of a series on the rules of writing good requirements, this article on valuable requirements explores the decomposition of goals, manifestation of strategy, and tracing to requirements. It uses the approach that a requirement has no value if it is not connected to a goal supporting a vision.
This is a great approach to figuring out which requirements you should work on. “With a set of problems in hand that are worth solving, you have to figure out which ones are aligned with your company’s strategy.”
Those are the requirements that your team truly must work on.
