“To Vie, or Not to Vie”: User Story Splitting By Task Assignee.
I couldn’t resist wording this subject after the infamous Shakespearan nunnery scene in Hamlet. However, as much as I’d love to say that I’ve read Hamlet in its entirety while sipping an excellent Sauvignon blanc from a custom crystal glass on the deck of my dream tiny beach house at Tarkwa bay, catching the ocean breeze to counter this Nigerian 35-degree Celcius weather, I can only be honest and just come clean…I’ve only read the monologue in the said scene. What? It’s the famous bit…
Anyway, sorry about that. I tend to get carried away when painting dramatic pictures of my thoughts. I’m a bit of an odd one, aren’t I? DO NOT ANSWER THAT!
Okay, for real though, where were we?
Yes, we were at the foreboding question that has lingered on the lips of most Product Owners, Product Managers, and software engineers: “To vie, or not to vie? Who gets the user story, the Backend engineer or the Frontend engineer?” or “Who should be in charge of moving a user story?” or wait…every PM knows this one, “Should I create separate tickets for Backend, Frontend, etc per any given user story?”. There are several message boards littered with variations of these questions. There’s a Jira Support Q & A page dedicated to this question. Stack Overflow. Quora. Reddit. You name it.
Quite frankly, all everyone wants to know is, in the spirit of being agile and writing conventional user stories, how are we supposed to assign one user story to different roles without creating a cataclysmic chain of events and a jumbled mess that is your board and team synergy? To this, I say there just might be an answer, and that answer is breaking each user story further into tasks for each person handling the story. I know it sounds quite cumbersome; unnecessarily so even, but, before you close this page in resignation, hear me out.
Let’s imagine that you need to write a user story for an institutional investor to search for and invest in companies. There are different possible personas for this scenario: a small business owner looking to invest on behalf of the company in order the spread its risk or a Hedge fund looking to hedge against risk on behalf of its clients/portfolio companies and so on. In essence, the main goal of this platform’s user is to ‘search for and invest’ but that’s too large a user story right? Yup! That’s where user story splitting comes into play.
So, you have split your user stories finely in the following ways;
- By persona
- By user type
- By capabilities, and probably
- By Device
and you have come up with two user stories such as the following:
USER STORY 1: “As a business user, I want to be able to search for listed companies so that I invest in them and spread my risk”.
USER STORY 2: “As a business user, I want to be able to click on a company in the search results in order to view more information so that I can invest”.
You have your user stories and then decide to throw them on your project-management software e.g. Jira, ClickUp, or Linear. On ClickUp, you can assign one story to multiple individuals but if memory serves, you can’t on Jira and most other PM tools. No worries. That’s not even the big issue. The big issue is that even if one ticket can be assigned to several people such as the Frontend engineer, Mobile, and Backend if one person moves the ticket or changes the status even though nobody else can confidently change the status accordingly, then we have a problem. So, in that case, the story is fine as is for the Product designer, Frontend, or Mobile engineer but things get tricky when we throw in the Backend guy/gal.
I’ve seen situations whereby the PM or Product Owner chose to create several boards to manage tasks for each team — Design, FE, BE, Mobile. You could do this but it’s a highly inefficient and brain-draining way of managing your cross-functional team’s tasks. You could also choose to not give a flying you-know-what and create only one user story — You know, throw caution to the wind, live a little on the edge, and allow all parties involved to duel to the death and figure it out — who cares right? Uhm, wrong. Very wrong.
Another way would be to create sub-tasks under each story for each assignee and assign the tasks accordingly — which means that the task can’t be marked as done until everyone’s done their bit on it. I think this might be the best way to go despite the fact that it could cause lags. I’m of the opinion that if the sprint is planned properly and the tasks are assigned time estimates/story points, you don’t overburden your team, and tasks still get finished within the allocated timeframes.
If you’re worried about repeating the user story in the sub-tasks, I believe the best option would be to become best friends with these three things;
- Your ‘Duplicate task’ button
- Your dependencies/issue-linking functions
- Your HTTP requests — GET, POST, PUT, PATCH, DELETE
As a Product person, learning HTTP requests makes your task of user story splitting by assignee much easier, especially when the main issue you have is duplicating or figuring out what endpoints the Backend Engineer will need to create. It’s easy to learn and allows you to understand and test your product’s API documentation especially if you’re not technical. You can check here for an easy explanation of the requests.
We may not have completely solved the issue of codependency with the sub-tasks solutions but hopefully, I’ve made life a lot easier for you, if you were wondering.
N.B: Please, don’t create multiple projects/boards to manage your small Xfx team’s tasks. It’s the most ridiculous solution. You’re welcome. :)
