Frontend vs Backend User Stories

A discussion on how to split stories

Should we or Shouldn’t we allow frontend (FE) and backend (BE) specific user stories? Surely, stories should describe features, something that delivers value? But what, if there was a public API? And if it turns out that API also fed a GUI frontend? And what if your team simply demanded it as it made their lives easier?

This post builds on a recent post and podcast where my colleague Swathi Poddar and I discuss how to best split / assign teams, and addresses the strange issue of whether you should be writing Backend and Frontend specific stories or not. While it is certainly worth to read the post, here are the highlights of our discussion (it is worth to check out the previous post / episode before going any further):

Swathi Poddar is a Business Analyst, Product Owner and Software Consultant. She has worked and studied in the UK, US and currently works out of Pune and Bangalore, India.

The illustration below is maybe helpful to illustrate what we are talking about:

Good user stories

1. Deliver value, so they need to cover some ‘end2end’ functionality. Something where an action leads to a measurable and valuable outcome.
2. Can be delivered
   Stories must be sufficiently small so we can understand them, reason about them and deliver them within a practical timeframe (usually days more than weeks).
3. Facilitate delivery
   Stories are a communication tool, so they need to make sense in the wider context of what we are expected to achieve. If they are too big we cannot deliver confidently, if they are badly ‘split’ or ‘sliced’ they make no sense and if they are too small we drown in noise.

How to split / slice stories

We can split a domain horizontally, vertically or in any other weird combination of both. But, we need to adhere to the above principles.

For your team’s sanity it also makes sense to have some consistency and uniformity in how we slice stories.

Backend vs. Frontend stories

The default reaction should be: Don’t do it. It violates principles 1 and 3. Focus on end 2 end, and if there is a frontend, specifically a GUI frontend, then that must be included in the story.

Wrong
Story1 — [BE] Derive price based on location
Story2 — [FE] Display price to user

Right
Story — Display location based price to user

Consider this in the context of actually writing the BE and FE story: “As a [what?] I want to calculate the price?” Hard to justify value in that.

But what, do you say, if the user is a system?

Here is where we get to the exemptions. We believe it may be ok to write BE and FE specific stories in the following cases:

• Where the BE provides value in its own right
  An example would be a data purging related story. But remember, any valid story must and will provide value to some business user directly or indirectly (otherwise we must not play it).
• Where the BE exposes an (often public) API and the customers of that API are end users (your frontend alone doesn’t quality!).
  In this case the requirements of the consumer of this external interface need to be specifically recognised and more often than not require user experience or service design to be delivered well.
• Do not see a GUI frontend simply as something to be added on like a facade. It’s requirements towards supporting interfaces are highly specific and often very different from those of system to system interfaces. Be careful with the BackendForFrontend pattern (see Sam Newman’s book below). This may provide a solution to bridge the gap between FE and BE but this comes at a cost.
• Where a story would be too ‘big’ or complex. In this case we should make very clear that the split is solely to facilitate development, but BE and FE build happen in conjunction.
  It is important that in this case we maintain a clear relationship between all these stories required to ultimately realise value.

Don’t

• Do not succumb to the temptation to first do all backend work, and then later, do the frontend on top. This is dangerous as
  a) you may not delivery real value unless the FE is completed, which goes against all lean values
  b) often a GUI frontend has very specific requirements that go beyond that of a system to system API, so you may have to massively add on or even restructure your backend
• Do not devolve frontend work to a ‘Frontend Team’.
  Because that would mean tightly coupling teams which is an antipattern (see Episode 14).

Our guest in this episode is Swathi Poddar, Business Analyst, Product Owner and Software Consultant. She can be ‘found’ and contacted here.

Stuff to read

Books we touch on in this episode, and which are highly recommended to ready are Sam Newman’s Building Microservices.

Interested in more Agile thinking, want to get in touch, share thoughts, collaborate with us in an episode or work with us?

Burn Up Media