Let's take the below user story as an example to understand the whole scenario better:

As a user, I should be able to contact a dealer to test-drive a car.

The scope of the story is that the user should be able to submit a test-drive request to a registered dealer. This can be done simply by filling a form which internally calls a REST API.

Now here are my questions:

  1. Should I try splitting this story at all?
  2. Should I create a separate story for creating a REST API? As the creation of REST API follows the I.N.V.E.S.T. guideline. To me, it appears as a complete vertical slice.
  3. After splitting, how should the rest of the story look? Does it look independent?
  4. Would it make any difference if API is managed by the same or different team?

2 Answers 2


Should I try splitting this story at all?

If it follows Estimable, Small, and Testable, no. If it doesn't, maybe.

Should I create a separate story for creating a REST API? [...] it appears as a complete vertical slice.

I disagree. Consider the I and the V. Each story must independently provide value. Say you make your API and do nothing else. You then give it to the user... I would expect most users' response to be "What the heck am I supposed to do with this?".

After splitting [...] Does it look independent?


Would it make any difference if API is managed by the same or different team?

Yes, but also keep in mind that Teams should be cross-functional. A Team should be able to complete any story in its entirety. If this is not possible, a (sub-optimal) solution is to split while invalidating INVEST, true. Another solution is to restructure/grow Teams to become cross-functional.


Part of the challenge is that "As a user" doesn't tell me who this is for, so it is hard to say if it is valuable. If it is "As a developer of 3rd party websites" then yes, REST API would be an independently-valuable. However, if it is "As a prospective car buyer" then it is certainly not independently-valuable.

To take this further, let's say it is the second option. Now I'd ask why it needs to be split. Are you just putting in your name and sending a message to the dealership? If this is more than a week of work, then there are probably other conversations about the complicated architecture or development process that need to be resolved before the team can reasonably try to complete backlog items in a shorter time frame.

Now, let's say it's more complicated. Perhaps there is a map that they select the dealership from, it pulls their schedule, then you reserve time on that schedule and it updates it with your appointment. Now we can split in some interesting ways. For example, seeing a dealership's schedule (and in particular, when is a good time) is potentially valuable for a car buyer by itself, so I'd look to deliver that as a full feature. If that is too complicated too, perhaps just pulling the schedule from one dealership or a subset is still valuable to some user set.

Alternatively, you could build a request form that emails to the dealership and later connected it through an API. There's an interesting nuance here because the followup backlog item is building the API but because it's building on the existing request, it does deliver value.

It is also worth pointing out that knowledge value is just as important as realized value from a user. Sometimes taking a first pass as some feature and putting it in front of potential users gives you a better idea of the "best" way to implement the feature.

One last thought: Ideally, each team has the ability to deliver any feature completely with just the people in the team. In most cases, this is absolutely possible, it just requires people to branch out of rigidly-defined roles and responsibilities. There are some industries where this isn't possible or you may simply find that it isn't possible YET. If you find yourself in this situation, then it is important for those different teams to create a strategy to work together more collaboratively. I should stress that if you are practicing Scrum, those teams should be working together to finish the backlog item in one sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.