Attainable Requirements

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.

Attainable Requirements – Revisiting

A little over three years ago (ten unicorn years), I wrote Writing Attainable Requirements, as part of the Big Rules of Writing Requirements series. In that article, we focused on the unique situations that every team faces – politics and people, and the shared challenge of implicit practicality. Those factors are as important today as they were then.

Defining Attainable

Attainability, for requirements, is simply the answer to the question – can this be reasonably done? Most, but not all, of the answer to that question comes from understanding if your team can build and test a solution to the problem you identify with your requirement. Being able to create a solution requires that the problem you’re solving is tractable, and that the team creating the solution has the skills to solve it.

Being able articulate a problem and it’s solution is necessary, but insufficient – solving the problem requires that there be a feasible solution.

As the founders of the agile development movement explained in their pitch for “low overhead” process – people trump process. I think it was Alistair Cockburn who added, “but politics trumps people.”

Finally, process is the often-overlooked element of determining attainability. Realizing the benefits of a novel solution to an existing problem usually involves process changes – sometimes significant ones.

The next few sections go into more detail on each of these – tractability, feasibility, people, and process.

Tractability

Goldilocks ruled out the large bed because it was too large. Eating the elephant, drinking from the fire-hose, boiling the ocean – these are all common phrases in the American vernacular, because so many people try to do too much (at one time). There are many ways to decompose a large, intractable problem into smaller, addressable components. Practicality requires that the problem you’re trying to solve is not too large.

If everything you do is small, however, you won’t ever accomplish anything big. That’s where strategic product management shines. As part of understanding your market, you identify large, valuable problems to be solved. To solve those large problems, you have to break them up into smaller problems, and then address them individually. You also have to make sure your team understands the big picture and the larger problem that ultimately needs to be solved. A great way to share context while decomposing problems is with the use of Ishikawa diagrams.

And zooming in…

Maintaining context is a particularly critical component of working with agile teams, where each deliverable’s possible size is constrained further to what a team can accomplish in an iteration.

[click for larger version]

For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog. And your agile team will move forward into managing their own execution from the product backlog stage. For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.

The same Ishikawa diagram, with more detail, looks like the following:

[click for larger version]

Agile Product Management: Providing Context

This reduced granularity represents the smallest go-to-market atomic requirement. Further decomposition results in smaller requirements, but they become too small, because they are no longer independently valuable. I’m not talking about “the sum of the whole is greater than the sum of the parts” stuff here – I’m talking about “if you only get X, without Y and Z, it has no value” stuff.

Feasibility

Even after decomposing market problems into addressable chunks, you still have to make sure that there are feasible solutions. One of the brighter software developers I worked with back in the day used to say “We’re writing software – it’s all ones and zeros – we can do anything.” He also followed that up with “…but should we be doing that?” The team I was working with at the time probably could do just about anything. But not everything can be done with a given budget and a specific deadline. Some things are simply infeasible.

Scrum teams measure velocity – a reflection of how much software they deliver in a given iteration, as a function of how much work they believe is involved in delivering. This is a great “protected” measure of efficiency. The team is protected from requests to do work that has little or no value – by measuring throughput in terms of effort, a team can get more efficient at doing more. A requirement is infeasible, and therefore unattainable, when it exceeds what the team can accomplish given a fixed amount of capacity. Project managers refer to this as the Iron Triangle – given scope, cost, and quality, pick any two as inputs and the third will be a variable output (absorbing the impact of uncertainty that arises during the development process). I prefer to use timeboxes rather than that rusty old triangle, to emphasize my perspective that quality is inherent in delivery, and should not be a “variable output of uncertainty.” Because quality is what usually bears the brunt of uncertainty.

plus yields

When the solution to a defined problem is prohibitively expensive, it is not attainable. The notion of cost should also be considered in the context of value. Requirements with higher value can justify implementing solutions with higher costs.

Prohibitively expensive solutions make requirements unattainable. Relatively expensive (relative to their value) solutions also reflect unattainable requirements. You need to collaborate with your implementation team to understand the costs associated with any particular requirement to know if it is attainable. This is one of the strongest arguments against throw-it-over-the-wall interactions between product managers and implementation teams. Without that feedback about feasibility and cost of a solution, you can’t assure that the requirements you are proposing are attainable.

Regular readers of Tyner Blain will realize that this is just an alternate way of stressing the importance of considering ROI when defining requirements.

Politics

There are political realities that every organization faces. It could be a benevolent dictator CEO, or an executive with an agenda or pet project. It may simply be that there is value in the problems you’ve identified, but solving them is not aligned with your corporate strategy. You may be focusing on dominating an existing market, where expansion into new markets is the company’s focus – or vice versa. You may be focusing on top-line growth opportunities, while the company is fixated on cost-reduction in a time of economic contraction.

Each of these scenarios causes you to be fighting an uphill battle internally. When that hill is too steep, you’re writing unattainable requirements.

Process

When deciding what to build, you also have to think about how you launch. Launching, as Dave Daniels regularly points out on his Launch Clinic blog, is not just putting your product up on your website for sale. You have to think organizationally about all of the other moving parts:

• Do your customers have the ability to absorb an update to your software?
• Can your customer service reps be trained in time to promote and support the new capabilities?
• Will your sales team be able to communicate a message that helps them close deals based on what you’ve just built?

Process is more than just the process of typing, compiling, and testing code. Process includes everything needed to successfully go to market and sustain your product. If you’re defining requirements that are too far ahead of your market they are not attainable. If your requirements embody process changes that are too difficult or expensive for your customers or your organization to absorb, your requirements are not attainable.

Conclusion

Attainable requirements are requirements that

• Have a reasonable cost to implement,
• Are aligned with your company’s strategy and stakeholder’s agendas, and
• Result in solutions that can be consumed by your company and your customers.

Make sure you’re writing attainable requirements.