Should Product Requirements reflect vendors' APIs capabilities and limitations?

Question

I have a question about the responsibilities of the Scrum Product Owner and the Scrum Engineer/Architect.

It is said that in Scrum the Product Requirements (PRD) specify the "what", but not the "how". In other words, PRD should not dictate (or be concerned with) the implementation details.

We are building an app that relies heavily on the interaction with vendors' APIs. It has been said that we don't want to couple our app tightly with vendors' APIs and therefore the Product Requirements should not reflect the vendors' APIs capabilities and limitations. More specifically, the PO is expected to write the Product Requirements in the absence of vendors' APIs documentation.

Is this the correct interpretation of the Scrum methodology? What are the advantages and disadvantages of this approach?

Answer 1

If product requirements are written in the complete absence of any third-party APIs, it is very possible that the resulting story will be very complex (i.e., worth a lot of points) or even impossible to implement. Neither of those are good stories. What the PO writes may be the end goal, but the development team (via product backlog grooming) can come back and tell the PO to rewrite the story or drop / change some of the requirements, based on their knowledge of the APIs they are using.

Alternatively (or in addition), if there get to be a lot of these kind of stories, it may be time to write a story to change the vendor product you're using to one that supports all the features that the PO wants. Of course that has a cost associated with it (both time and money) and would be up to the PO to decide where to prioritize it in the backlog.

Answer 2

This isn't a question is really about requirements engineering and is independent of Scrum and the Product Owner role.

All requirements should be concerned with what the system under design does and not how it does it. This is simply the one of the characteristics of a good requirement and doesn't change depending on your life cycle methodology, your process, or the system that you are designing.

With respect to vendor APIs, there are really two ways to think about it.

You can use the requirements to select vendors. That is, your requirements specify what you want the system under design to do. When evaluating vendors, you ensure that any APIs that they provide are capable of meeting those requirements. Failure to meet the requirement would lead to the vendor being disqualified from selection.

Alternatively, you can use vendors to drive the requirements. Your system will only provide functionality that is broadly available through the vendor APIs. If certain functionality is not available, that would cause you to remove the requirement from the system under design, either in general or in the case of an integration with a particular API.

There's no one right way to do it. It depends on the type of product that you are making. You can either integrate with more APIs and have various levels of functionality based on the external APIs or limit the APIs that you interact with to those that provide what you need to function. In the context of Scrum, that would be the decision of the Product Owner as part of managing the vision and direction of the product.

Answer 3

Scrum's answer is that yes, the product requirements should be expressed without any voluntary censoring. In fact that can be very limiting and I've seen it happen where some options were not even mentioned in the decision process because they were implied to be not viable without said fact being questioned.

We also favor collaboration over contract negotiation meaning if new facts arrive, we can consult with each other and make changes as needed.

I like to use a process borrowed from Kepner Tregoe Decision Analysis, which is about having clarity on must haves and should haves. You can read about it here.

Now, it's not unheard of that 20% of the requirements drive 80% of the cost. This likely will come up during estimations. As a scrum master I have found it useful to review this with the PO, and discuss potential alternatives. I've had both kinds of responses, too, sometimes the expensive requirement was a core part of the deliverable, sometimes it would be returned to the backlog.

Answer 4

Requirements should be there to provide benefits. On the other hand, fulfilling requirements will produce cost. If the cost of fulfilling a requirement outweighs the benefit, then someone should be thinking about dropping the requirement.

The product owner likely is informed about the benefits of a requirement (or is in a position to find out from stakeholders). The scrum master will at some point find out the cost of fulfilling a requirement, hopefully when it is estimated, worse if a developer figures out that he or she cannot deliver a story in nowhere near the estimated timeframe.

The product owner shouldn't self-censor in their requirements. Likewise, the development team shouldn't blindly implement the requirements, without any consideration of the cost. If there is generally good communication, then the team will have some idea of the benefits of a requirement, and can warn if the implementation cost is high compared to the benefits. Alternatively, the product owner could specify what an acceptable implementation cost for a requirement is. For example, "I expect the cost to be less than 8 working days of one developer, and if it isn't significantly more, then I don't want it".