User Stories breakdown for back-end team

Question

I'm a product owner without any technical background especially without a correct sense from the back-end development process and tasks. I have a brief knowledge about MVC architecture but our team uses customized architecture so I'm almost blind to the technical concept of back-end part of our project.

The problem appears when I want to breakdown user stories into tasks with the back-end team. I cannot understand anything about their tasks and I just jot down their orders and then import them to the JIRA.

When a task was done, I can't realize what part of the project has been progressed, because usually the tasks are related to many user stories. In fact, the back-end team told me!

I have this problem with neither the mobile team nor the front-end, because their tasks have a pattern so I can predict the other user stories' tasks based on it and understand them.

So is there any template or pattern for Back-end tasks or any related hint?

Answer 1

I am assuming you are using a Scrum process, but the core of the answer will not be significantly different for other agile processes.

The core of your problem lies in that you try to coordinate the work within a team or between teams on a technical level without understanding all the technical details. The solution here is not a particular template for tasks or a particular way to break down the work, but rather to delegate that coordination to the people that should have the knowledge: the team members.

The first thing to do is to make sure that all the developers know which stories depend on each other. This is relevant for the developers, because it highly influences their decisions what to pick up next.

If the coordination is within one team, then the daily standup meeting is exactly intended for this kind of coordination.

If the coordination is between teams, then I recommend looking at the various scaled agile frameworks. The easiest would be a Scrum-of-Scrums meeting, in which representatives of each team coordinate with each other to get the work that touches multiple teams done as effectively as possible.

Answer 2

The Product Owner doesn't need to care about Tasks.

You should not be creating them. You should not be looking at them. You should not care about them.

You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them.

There is no such thing as a 'half-finished Story'. A Story is either Done or not. If it's Done, it's burned down. If it's not, then it's not Done.

No Story should take longer than a single Sprint to complete, so you shouldn't need to care about such fine-grained progress details as Tasks. If they're not, then split the Stories so they become smaller and accomplish-able in one Sprint.