How to split stories depending on APIs?
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:
- Should I try splitting this story at all?
- 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.
- After splitting, how should the rest of the story look? Does it look independent?
- Would it make any difference if API is managed by the same or different team?
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.