2

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?

2
  • I've provided an answer based on my understanding of the question, but reading it carefully I have the following question: Are these technical tasks in the sprint backlog, or in the product backlog?
    – Bogdan
    Feb 1 at 18:09
  • They are in the product backlog and I take your first answer. Yet your second answer is also relevant to my situation.
    – FloFu
    Feb 2 at 8:01
3

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.

For the Product Backlog

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.

For the Sprint Backlog

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.