Categories

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 2

In the first part of this topic (Same team working on new features and production support), we talked about the problem that is there when a Scrum team has to work on new features as well as on production support of the existing releases, its impact on morale, and how if the Scrum team does not take this support into account, then their planning and estimation will fail because the time required for this production support has not been taken into account.
In this second part of the post on the topic, we discuss more on how a Scrum team can take this effort into account and ensure that this work is properly accounted for. Going down this path will help the Scrum team to account for their time spent on both of these activities, and also inform the stakeholders of all the efforts put into these 2 different projects. The first and foremost task is for the team to determine what is the extent of effort would be to do production support. Once this effort is know, and it is greater than 10-15% of the total amount of effort available by the time, then production support needs to be accounted for separately.
One way that the teams account for and allocate time for such production support is by creating a separate backlog that is meant for production support. Both the backlogs for new features and production support are done by the team, with the Product Owner determining the extent to which the amount of effort from the team needs to be allotted to the Production Support backlog. Through this method, the team is able to review the progress in both the list of new features as well as the bugs (and other production support activities) in the Daily Scrum.
Another way is not have a separate backlog for the production support, instead there is one common backlog for both sets of activities. This makes the prioritization and allocation of tasks much more complex for the Product Owner, but also makes for better decision making and trade-off between new features and production support. This trade-off has to be explicitly made, which ensures that the proper business decision is made (rather than allocating a ratio between 2 separate backlogs, which sometimes means production issues are fixed that are less important than new features). To increase the chances that these production issues, which are deemed less interesting for the Scrum team are fixed, they are compared with new feature work that is going on, and wherever the production issue aligns with new feature work, fixing the production issue can be made as one of the criteria for marking the new feature work as done. Of course, this means that some amount of effort may be spent on a production issue that is slightly less significant, but would otherwise never get fixed on its own. An advantage of adding such bugs to the criteria ensures that these bugs will remain fixed and tested for in future versions of the software as well. And of course, there is opportunity to learn, since production issues means that the testing criteria used in the past missed something.

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>