Approach to managing and prioritizing Technical Tasks
Hi all,
Here I wanted to discuss a good way of managing technical tasks. What seems to work well is a user story with business requirements and acceptance criteria written by a Product Owner. Devs create technical subtasks under a user story (you can’t expect a PO to know technical details).
The problem with the above is that in most cases it takes longer than a single sprint to complete all sub-tasks under a user story and that creates spillover. We try too break down user stories as much as possible but there is only so much breakdown you can do before you lose the business value the story is meant to deliver.
What devs are currently doing is raising technical tasks (not sub-tasks) under the same epic. These technical tasks duplicate the business requirements in the PO tickets.
This also makes prioritization much more difficult. The technical tasks get created after we have already prioritized the PO ticket. If we wanted to prioritize the technical tasks as well, we’d have to fish them out of the backlog one by one.
Can you share your experience on managing and prioritizing technical tasks?
The problem with the above is that in most cases it takes longer than a single sprint to complete all sub-tasks under a user story and that creates spillover.
Why? Why does the scheme you describe actually hinder the Developrs' ability to estimate those user stories, and to get their arms around how much work they can take on this Sprint?
How long are your Sprints?
Our Sprints are two-weeks. Developers can estimate of course, but then again those estimates in many cases would be more than what is achievable in a Sprint.
My favorite strategy is Kanban. I'm sure you know it, but still. The main idea is to highlight the most important tasks, without which the sprint itself cannot be called successful. Then there are significant tasks that will add to the success of the final result, but their failure or incomplete completion will not lead to the death of the sprint. And then there are the next - so to speak, side tasks.
If we do it, it's good, if we don't, we'll do it at the next sprint. It may be that after the review, it turns out that these tasks were not needed at all.
The point is this. If you work in an office, you should have a big whiteboard where all these tasks are posted, and every sprint participant can see them. If you're not in the office, you can use a convenient service like Miro, Jira, Trello, etc.
For convenience, you can categorize tasks, divide them into colors, mark them with emoticons, give bonuses for solving a task faster than planned, etc.
The main thing is not to repeat what led to the failure of the sprint. Experiment and find your own way. In my opinion, it is experiments that lead to the creation of a culture of both the company and its individual departments.
And of course, it happens that the problem is not the number of tasks, but the communication of the people who perform them. In this case, contact People Partner.
I realize that I don't have a magic pill to solve all problems, but we are all human beings, and we have to find our own way. For us, this is a constant, relaxed communication.