How do I distinguish/identify different jobs between occupations in Jira

Question

Suppose my team is going to develop a system, which includes sign up, login, password recovery and lots of other modules.

There are an UI designer, a PO, a front-end engineer and a back-end engineer in my team. To track their work, I could create some stories, e.g. sign up jira story, login jira story, password recovery jira story

and then create 3 groups of sub-tasks under corresponding jira story respectively. For example, under jira story sign up, I create sub-task sign up - product definition for PO, sign up - Front-End for front-end engineer, and so on ...

under jira story login, I create sub-task login - UI for my UI designer, login - Back-End for my back-end engineer, and so on ...

Each Jira sub-task is also tagged a "Component/s" field correspondingly, for example, sub-task login - UI is tagged UI.

Is the process above a common way to track the development of a project?

Answer 1

Is the process above a common way to track the development of a project?

No. In Jira, you have a status field. This field is configurable in a workflow. The administrator can define what options exist and how you can change from one option to another.

For example, your Aministrator could have used the options "Requirements Gathering", "UI/UX Design", "Coding", "QA", "Complete" and they could have made it so that you can skip "UI/UX Design" and go straight to "Coding", but you cannot skip "QA". Or they could use any other workflow you can come up with. I think I said it in another question, Jira is the tool that you need to configure to fit your companies workflow.

I have seen two practical reasons for subtasks: technical reasons where you need to reference two distinct numbers even though it's the same story (for example frontend dev and backend dev both need an id for their commits, but don't want to use the same to not mix things up) or actually independent tasks that can be carried out asynchronously.

Answer 2

In principle, yes, in that almost every story will involve work from every craft (UX, Backend, Frontend, QA). However, what strikes me as strange is the fact that every story is supposed to have the exact same set of tasks. For example, "sign up" and "login" sound similar and will involve related systems, but "sign up" probably involves more work (more data to be entered by the user, email validation etc). Maybe one is more Backend-heavy than the other. Maybe one requires usability testing or market research while the other does not.

In trying to simply break each story into the same 3 sets of tasks, you're missing out on the opportunity to break them into more meaningful chunks. For example, the UX/UI task may consist of sub-tasks like "do market research", "create initial wireframe concept", "create a prototype", "test prototype with client", "create finalised concept", etc. Of course, the breakdown doesn't have to be nearly as finegrained as that (and might, in fact, be different for each story), but having clearer titles will make it easier to talk about tasks that are blocked, in progress or ready for testing. Unless your team consists of exactly 1 person from each craft, having smaller tasks also makes it easier to split the work. It's also easier to verify the definitions of done if a task is small and well-defined.

Components for crafts can be useful if you set up filters to make it easier to either search for specific tasks, or only view tasks relevant to a certain craft. (For example, a Backend developer who just finished her current task will want to check out open Backend tasks to pick her next task.)