Cutting stories for MicroServices

FrontEnd and BackEnd teams

Front End Story
As a
User
When I click search
I should see results
So that I can navigate to a result

Back End Story
As a
FrontEnd
I need the Backend
To give me search results 
So that I can show it

These sound like good stories, right?

I have seen this happen several times in the past year after many projects have started adopting API based architectures. The topic of how we split teams and Full stack vs FrontEnd/BackEnd Developers, is beyond the scope of this discussion. However splitting stories in this manner is interesting because the consuming entity is considered as a persona. In this case “FrontEnd” is being considered the persona.

Architecture of an application is purely an implementation detail and that should never govern stories. In my opinion, in this specific situation, we do not need a backend story at all. All we need is the story to be picked up by the FrontEnd and BackEnd developer together and delivered as a single unit of work.

Sounds simple, however how the two Developers work together also matters. In many cases the FrontEnd and BackendEnd Developers agree on an API contract and start work in parallel. In rare cases I have even seen Backend Developers completing the API before FrontEnd Developers start work.

This unnecessarily forces them to think about the API contract right in the beginning and also potentially delays identification of integration issues to the very end. A better approach in such cases is to start with interface and then come up with the API based on what the UI needs. The backend Developer should only begin work after the FrontEnd Developer has come up with a working stub.

MicroServices

Enter MicroServices and this problem becomes even more pronounced. Lets say you are writing up the requirements for booking a movie ticket and about 3 services are involved, lets consider below stories.

Payment
As a
BookingService
I need the Payment Service
To debit Customer Account
So that I can complete the booking

Audit
As
PaymentService
I need LogService to log the transaction
So that I can be audited

Booking Confirmation
As
BookingService
I need NotificationService to send an SMS
So that I can send ticket details

….

You get the idea.

This is a really big problem now because the feature is absolutely not traceable across stories. We could argue that these stories can be part of a Booking Epic. However that still does not cut it.

How do you estimate and trace the progress of this feature. The customer does not care if we are using MicroServices or Monoliths. She just needs to book a movie ticket. And she is the Persona we care about.

So, how do write these stories?

Payment
As a Returning Customer
I would like to make a payment
So that I complete my booking

Audit
As a an Accounts Manager
I should be able to show logs of all payments
So that I can obtain a compliance certificate

Booking Confirmation
As a Returning Customer
I would like to receive a SMS notification after completing my booking
So that I can present the same at the box office

Note how we still have stories for each service. The key difference is the context we have captured. For example, earlier we could not tell why we have log all transactions. Now it is clear which Persona requires it and why.