Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
What to do when the programmers from the dev team want to put their development tasks in the product backlog (such as refactor XXX, clean class XXX, ...)?
We tried and have the users stories mixed with (a huge number of) programmers task that are hard to understand from the Product Owner point of view.
Is there any good practices to store developers task?
It's not clear to me if you are referring to the Sprint backlog or to the Product Backlog so I'll add an answer for both.
Create two epics called "Refactoring" and "Technical debt" (or any other large category of work you find necessary). Don't add any stories to the epics. Instead, add all the development tasks as a list in the description of the epics.
Keep the epics afloat somewhere on the top of the backlog (i.e. "in your face") so that you don't forget about them or neglect them.
During Refinement Meetings or Sprint Planning meetings, decide with the team if you want to do any work from those lists. Chose the work you want to do from the lists and extract them as separate stories (update the description of the epics to remove these items).
Work on these stories during your sprint.
Rinse and repeat.
And finally, during Retrospective meetings, discuss why you have so many tasks of "refactor X, clean class Y, etc". There might be an issue there and a sign that the team is creating a mess and then later on needs to go back on work already performed and clean it up. Maybe some new technical practices need to be considered, maybe the team is bad at estimating and they rush the sprints causing the issues, maybe the Product Owner pushes too much the development team, whatever it is... The question should not be how to manage the huge number of tasks, but how to create less of them.
If these are tasks for the user stories in the Sprint then there isn't necessarily a problem. The development team owns the Sprint Backlog and if they find it useful to add tasks there and helpful for doing their work, then they should do so. The Product Owner should just look at the User Stories themselves and ignore the technical stuff.
If there is a huge number of tasks, then maybe the team is decomposing their work in very little pieces. Again, that's not necessarily a problem, but it might cause some waste if a lot of effort goes into it. From my experience, inexperienced teams tend to do this as it gives them a little more confidence that they have understood the work that needs to be done. If you are worried about it, then again, you can raise a point in the retrospective and discuss it.
