How do you separate front and back tasks on a project?

Question

Project management

Colleagues, experienced RPs and team leaders, share your experience, please:
There is a product, a common platform with a clear division into back and front, and, in addition, there is a division into 7 project branches, so tasks on all branches with operational switching run in parallel. Tasks are set by analysts who do not have the competence to divide B / F. Therefore, earlier, when a requirement arose, two tasks were set in Redmine, with the same description, but separately for the back and front. But two tasks in RM are two entities for one, in fact, logical requirement. And, in addition, often the front turns on when the back has done 60-80% of its work. Therefore, I do not like this system with two tasks, but leaving it and setting one task, you cannot parallelize the work of B / F.
Tell us, how do you set tasks on projects, you or analysts, and how do you control the execution of tasks by the back-front?

Answer 1

You have Redmine, which means you have a User Story - the top level and what is usually called a task. Stories are already fighting for tasks (usually called subtasks). Why so:
- users are "stupid" and are not able to set tasks. they express "wishes" and therefore these are "user stories".
- tasks are created by the team leader, breaking stories into sane parts for individual people.
- if history = task (oh, miracle), then you can not set the task separately

Answer 2

Timlid indicates in the comments when transferring the task to the performer.

Answer 3

If you have a "clear" division into front and back, then, in fact, you have 2 technical projects interacting with each other. And they cannot have the same task, because they do different things.
Judging by the rest of the text, you do not decompose tasks, hence such questions. Then, you have 2 options, start decomposing tasks into separate subtasks, where there will be a separate performer, you can estimate labor costs, indicate dependencies, etc. In addition, in redmine, you can build a tree structure of tasks out of the box. Then you will have at least some control and you will be able to plan. Or do not bother, because. 1 or 2 tasks will not affect the situation, and let the developers themselves divide tasks and plan.

Answer 4

And, in addition, often the front turns on when the back has done 60-80% of its work.
wtf?
You implement specific features. As a customer, I wouldn’t give a damn that the fronts did everything and well done, but there are no backs and the feature doesn’t work as a result, de facto, sorry, all the assholes)
We need a top-level task “feature such and such”, which is already beating for technical tasks ( BA, SA, Dev, QA) and only then, when all the pieces are done and tested (separately and together) - release. At the same time, within the framework of one task, you can set up elementary sla in reports (we have jira) and understand where bottlenecks are in your process, where pain is, and where and why tasks freeze within specific features and dance further from this. It can change the working workflow, remove something, add something, increase backing resources, and so on.
We also implemented this approach a long time ago and backs were also lagging behind, and there were cases when the front released part of the non-working functionality for a battle in anticipation of a back, and the backs were pulled to higher priority projects, then again, then again, and as a result, the feature became relevant and they scored on it, and in the battle pieces of code and forms were bred (if you know how to get to them), which no one needs and does not work.