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.

Managing defects – a way to mark defects for future releases of the software ..

In an ideal world, a team would fix all the defects that have been found during a development cycle. And now back to reality; very rarely do development teams have the kind of resources and time available to fix all the defects that have been reported. When you do the trade off between defects and the resource availability, in almost cases, you will find defects that you are fine with not too fix. A possible reason is that fixing these defects will impact the schedule, and you are fine with letting these defects flow to the customer rather than impacting the schedule (and impacting the schedule is a critical activity that can have an impact on the revenue and public relations of an organization, so it can be a no-no except in very critical cases). Another reason for not fixing certain defects is because they come too close to the end of a development cycle, and fixing the defect may have an impact on the design. Such defects are evaluated very critically, and the risk because of the design impact can lead to a call being taken to not fix the defect and let it pass on in the current version of the product. There may be other reasons as to why defects are not fixed for now.
And with that, let us move onto the next release of the product. In every release of a software product, there is an initial period of time when the architecture and design work is ongoing, and the teams have not really moved onto the full pace of coding and testing. For the teams to be equally effective during this period, it would be useful to fix many of the defects that are of value to the customers and which were not fixed in the previous version. However, this cannot be done unless the team has implemented processes to mark certain defects that can be taken for the next version, and then taken them up when the timeframe for the next version rolls up.
So, what is the process that is needed ?
– During the development process for the next version, a category needs to be made in the defect management tool that would mark defects for the next version of the software.
– During the development process, the defect review committee would look at all the defects as they come by.
– For those defects that are not marked for fixing, the team needs to look at whether the defect is one that is important for customers.
– If the defect is deemed as one that would not impact customers, and is not important, then most of these defects would be deferred or closed, and not have anything to do with the next version of the software.
– Now, when you get to a defect that was not marked for fixing because of time frame but has some advantages for customers or for the workflow, it is fairly easy to mark it for the next version.
– For those defects that have a significant impact on the design, not all of them wold be marked as defects deferred for the next version. If it really has an impact on the design, then it should marked as a feature modification and not taken through the defect route, and closed accordingly from the defect database.
– Now, you have a list of such defects when you are in the early stages of the next version of the software development process. But that does not mean that you can simply take such defects as they are and mark them all for fixing. You first need to evaluate the amount of resources you have available, and then estimate the number of defects that you can fix with these available resources. Typically, the Product Manager plays a big role in prioritizing the defects so that it can be decided as to which are the ones that can be fixed and which cannot be fixed in the given time schedule.
This process ensures that several important defects that add value to the customer and which could not be fixed in the previous version can be fixed in the current version.

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>