Incorporating maintenance works in product backlog



1 comment

  • Avatar
    Ian Bridson

    Hi Guatam

    I think that having to support a system while still developing it is very common, so there will always be a case where a 'Production change request' is competing with new functionality in the product backlog and this has to be prioritised as normal by product owner. As you say this requires some analysis upfront to establish an estimate, but if these changes are small then maybe this is just confirming the change is valid or aggregating several similar changes from various customers into the one you think makes the most sense. Presumably defects arising during development are handled in a similar way at  a triage perhaps, and these CRs could be handled there too.

    Having half your resources working on change requests suggests that there are a lot of changes required, so taking a step back to look at the cause of the changes might help - Perhaps these CRs should be fed into the requirements process for the projects alongside new functionality, or are these more like usability issues that need to be addressed before release? 

    It seems that the main problem is that these changes are seen as different to new development, maybe because they are charged out differently or use a different cost centre, therefore resources need to be ring-fenced to make accounting easier (but not very agile), rather than looking at how best to deliver these changes and then working out how to account for them afterwards. This is one of the big challenges for a development team adopting agile - if the rest of the business functions don't also adopt different processes to support agile then it can hamper adoption by the development team.

    Comment actions Permalink

Please sign in to leave a comment.