If I could, I wouldn’t: Separate back-end and front-end user stories

In my experience with Agile projects, we usually have user stories that somewhat correspond to features. Under the user stories, there’d be the front-end task, the back-end task, the testing task, and so on. There’d occasionally be user stories that’ll only have the front-end part or only have the back-end part, and that’s done as needed by the requirement. But it wasn’t a case wherein you have that particular requirement and you split it off to back-end and front-end stories.

I guess it’s always the team’s call on how they would work. That’s what makes agile agile. But I’ve tried it, i.e., having separate user stories for the back-end and front-end part. And it’s not my favorite for the various reasons I’ll enumerate below. Maybe it’s also just me and how I agree with that Agile principle that “Working software is the primary measure of progress.” Technically, the APIs could work and they’re functioning as expected; and the screen components are front-end validations could also work. But it feels incomplete for me.

Anyways, onto the reasons….

Repetition, Overhead

There are a lot of details that we have to repeat in both stories for the same feature. Why not just link them with each other? Well, we do that but the back-end guys expect that they can just focus on the BE story, same with the front-end guys. So there’s overhead in the repetition and in keeping things consistent.

Dependencies

We have to line up the BE user stories first or a sprint ahead. Then while we’re grooming for the next sprint or a couple of sprints down the line, we have to remember whether the FE story has already been covered by a BE story. Of course, that’s what related links are for. But still, humans are human, linkages could be missed.

In case there’s a bug in the user story, but it wasn’t really in scope, typically in previous projects we’d just create the needed user story for it. We’d then decide if it’s something we can take on within the sprint, or if it’s something we’d have to defer. But in this case, we’d need to line up two user stories — first for the BE and then another one for the FE, and there’s the possibility that we can’t get them in the same sprint.

Maybe it’s just psychological, and maybe it actually is, but it feels like it takes longer to complete a user story (feature).

Bloated Backlog

You nearly have twice as much user stories. So it feels like the backlog is bloated. You see a lot of user stories and it feels like a lot of work, but it’s just for that single feature or requirement. Again, maybe psychological.

Demos during Sprint Review

There’d be demos of the FE story which is already an integration of the back-end along with it, so that’s the actual demo of the feature. But there are also the demos of the BE stories where the interface would be via Postman or via Chrome Dev Tool or via the SQL client. As a tester, you have some appreciation for it; but as someone who empathizes with the client or business, I wonder if they’re as keen on seeing that API response as opposed to seeing the integrated feature.

Coincidentally, a team mate just asked me for certain details of a user story

So while writing this post, a team mate asked me for certain details of a user story. As expected, the related API story was linked to a corresponding FE story. However, she was working on a related feature and so that one wasn’t linked to the original API story. So it had to take some searching to find the answers from her. I ended up answering from memory to give her quick feedback, but of course I had to do due diligence and cross-check with the actual story and then add the linkages. Anyway, I guess this is my cue to get back to work. Although at 1:27 AM, I think I can already call it a day.

“Potentially releasable“

[Edit Oct 22] At the end of the Sprint, I feel a better sense of accomplishment if there’s a feature that’s actually built. Not just the data model, not just the API, not just the front-end that’s blocked because it’s still waiting on the API. This ties up to the 3rd item I mentioned above. But as I was just browsing, I came across this page again: What does it mean to be potentially releasable?

• “The goal for any Scrum or agile team is the same: develop a potentially releasable product increment by the end of each sprint.”
• And of course, it goes on to describe what is meant by potentially releasable — emphasizing “potentially” meaning it doesn’t always have to mean that you release every Sprint.
• It shares and expounds on 3 key characteristics of the product increment to be potentially releasable: High quality, well tested, complete
• “…reaching a potentially releasable state as often as possible is simply a good habit for Scrum teams. Teams that miss reaching this standard often begin to do so more frequently or for prolonged periods.”

[Edit Mar 31] I googled to see what others had to say on this topic.

User story decomposition into frontend and backend

“As a rule of thumb (there are always edge cases and exceptions), user stories should represent a potentially-shippable unit of work related to the Sprint Goal. Unless you can ship the front end and back end capabilities independently, it doesn’t make sense to split a story based on who will be doing the work.”

Frontend vs Backend User Stories: A discussion on how to split 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.”

Quora: Do you break down user stories into separate front-end and back-end tickets?

(Loads of responses there in Quora)