A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum challenges – Handling cases where the same team has to work on feature development and also support of previous versions and fixing bugs – Part 4

This series on support of production issues and Scrum keeps on going on. At the end of the last such post, I ran into some issues buzzing in my head from what I wrote, and then a couple of colleagues talked about some exceptions that they had to make for production support, and as we discussed those, it seemed fairly clear that those were not covered at all in my post, so back to the blog for covering more items. This post will take some individual issues rather than trying to connect all the issues:
– When the production issues can occur for features that are not linked to the product that the current team is working on. This is possible when the team is working on multiple products, or when they released a specific product and then moved onto another product. In such cases, the Product Owner typically does not feel any responsibility for these items or for budgeting the effort for such production issues and may not have the required depth of knowledge to do so as well. One solution is to ensure that there is either a Maintenance Sprint, or a portion of time is set-out in each Sprint for the effort needed for production support.
– Things get complicated when the team reaches a stage where they have 2 separate branches – one for the maintenance branch dealing with production issues and the other dealing with the current ongoing development processes. In such cases, when an issue arises on maintenance that would seem to also affect the ongoing feature work, the handling of such bugs becomes critical. It is not a simple matter to integrate a fix from one code branch to another – the files in question may have changed during the course of new feature development, and to integrate the code fix will take time. Such changes take more time that would be normally expected, and when there are a number of such fixes, the effort involved can be considerable; and unless these efforts are tracked, it would seem that the team is losing out on overall effort available. What can make matters more complicated is when a bug fix is made on maintenance in one Sprint cycle, but because of scheduling constraints, it cannot make it to the new feature development branch in the same Sprint cycle. In such cases, if there are a number of such fixes that come up, then these fixes should be grouped as a part of one user story (referring to bugs arising from maintenance issues), and then fixed together.
– And then there are the cases when the team has budgeted for a certain amount of work for production support issues, but the actual time required is far greater. In such cases, when the time available with the team for such issues is over and these issues keep on arriving, then a call needs to be taken on whether extra effort needs to be allocated for the production support, or the line has been crossed and any additional product support can only be done in the next Sprint cycle. Both of these stands have certain problems and advantages, and one needs to weight these pros and cons.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>