Skip to main content

Maintenance vs increment workflow management

Last post 04:10 pm March 29, 2023 by Marcin Nagraba
4 replies
02:48 pm March 28, 2023

How to best cope with Increment task vs Maintenance (bugs, updates etc)? 



a. Mix all the issues in one poroduct backlog

b.  Divide work into 2 separate workflows (eg. increment in scrum, maintinance in kanban) 



thx! 


05:45 pm March 28, 2023

The Scrum Guide says: "The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

Don't just "mix" that work into the Product Backlog. The Product Owner needs to order it in relation to everything else.

How many Scrum Teams draw work from the Product Backlog, and the extent to which they may or may not use a Kanban workflow, is up to them. Regardless of how they self-organize, they will need to ensure that they integrate their work into a Done product increment of immediately usable quality at least once per Sprint.


06:09 pm March 28, 2023

I don't see a distinction between "increment task" and "maintenance" work. Both types of work represent something that is needed to improve the product. And since the Product Backlog is not only the "list of what is needed to improve the product" but also "the single source of work undertaken by the Scrum Team", putting everything into a single Product Backlog is likely a good option.

Do you see any advantages to maintaining two separate lists of work or following two separate workflows? What benefits would either (or both) have for any stakeholders?


10:13 pm March 28, 2023

How about stop trying to see the work as different?  As @Ian and @Thomas have said, it is all work that needs to be done in order to improve the Product.  Put everything in the Product Backlog and let the Product Owner order the items in a manner that ensures the Developers are working on the right things at the right time. Do not try to split them into different workflows because that never works well for a single team.  Doing that introduces competing priorities and splits the focus of people doing the work. 

I also recommend that you do not have a variety of "types" of items.  They all provide negative value as long as they are undone, positive value once the work is completed.  They all need to have clear descriptions, known behaviors, etc.  If you are using a product to manage your Product Backlog, such as Jira, only use one type of item.  Make everything a Story or a Task.  Don't differentiate because it encourages separate ways of handling and addressing the work. Make everything the same and it is much easier for people to see them as equally necessary.


08:12 am March 29, 2023

Thank you guys for help! 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.