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….
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.
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).
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.Continue reading