Scrum for SDK development - split stories horizontally?

Question

Our product is moving more and more in the direction of a software development kit (SDK) which can be used by other developers.

This brings up quite some challenges to our agile processes, though and I am searching for suggestions from people who have experience with this.

The main question we are struggling with is: how to split user stories, since we are disagreeing on who our user is. Are we planning for features from an end-user perspective (we currently ship the SDK together with a standard implementation, so everything actually has UI, etc. but customers can also adjust this standard behaviour to their needs) or is it enough to define a ticket in terms of "There should be a method in class X doing Y"?

In "normal" Scrum Teams, it's a bad practice to split user stories by horizontal layers but some team members argue that if we consider the SDK consumer as a user, then a ticket "There should be a method in class X doing Y" should be valid and that a separate ticket for UI for the same feature can be created since that one targets a different user/use-case.

I hope I explained well enough to give you a good understanding. I am happy to hear your thoughts, experiences and suggestions!

Answer 1

Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.

So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.

Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.

In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.

User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.

Run an experiment for 3-4 timeboxes and see how the team react.

Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.

Answer 2

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:

As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do.

and

As an interface user, I would like to be able to grant permissions to a user so that I can manage what different users can do.

Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.