This is an interesting topic about how to manage and prioritize the maintenance efforts in the scrum process.
From resource management perspective, the prioritization of the work for the same resource pool should be done together.
If the resources who are responsible for fixing bugs are the same resources who are working on the new features, fixing bugs vs developing new features need to be prioritized, so he or she know, for a given day, which work should be the focus.
The problem is that the size of the bug fixes may be small or big and the impacts of "not fixing" is unknown. If we let the product management to handle it and if the product management does not have the view of the product as a whole, including the sense of the product quality, but driving their priorities entirely by product features, we will be in trouble, as the bugs may not get enough attention.
Here are different options that can help us think and manage the bugs in a scrum process (from here):
If the product owner lacks the judgement, we may need to follow the option 3 or option 2, otherwise, putting the prioritization on the Product Owner is still the best approach as long as we have a right product manager that has the functional knowledge as well as the good sense about product quality.
Having a separate PQE team (or Sustain Engineering team) may be necessary if we are introducing a big project and we would like the team to have the focus, especially when the new product features are time bounded due to the customer commitment or time-to-market requirements from marketing perspective. Only if the resource pool is separate, option 3 makes sense.
The prioritization of bugs should not be based on # of customer issues raised in the support ticket. This type of thinking is putting the company at risk since it encouraging escalations. It should be based on whether a workaround is available and whether the broken area is on a critical process flow. If yes, even one customer is raising the issue is a high priority as it may be the first one, but not the last one.
From resource management perspective, the prioritization of the work for the same resource pool should be done together.
If the resources who are responsible for fixing bugs are the same resources who are working on the new features, fixing bugs vs developing new features need to be prioritized, so he or she know, for a given day, which work should be the focus.
The problem is that the size of the bug fixes may be small or big and the impacts of "not fixing" is unknown. If we let the product management to handle it and if the product management does not have the view of the product as a whole, including the sense of the product quality, but driving their priorities entirely by product features, we will be in trouble, as the bugs may not get enough attention.
Here are different options that can help us think and manage the bugs in a scrum process (from here):
- Product owner prints out the most high priority Jira items, brings them to the sprint planning meeting, and puts them up on the wall together with the other stories (thereby implicitly specifying the priority of these items compared to the other stories).
- Product owner creates stories that refer to Jira items. For example “Fix the most critical back office reporting bugs, Jira-124, Jira- 126, and Jira-180”.
- Bug-fixing is considered to be outside of the sprint, i.e. the team keeps a low enough focus factor (for example 50%) to ensure that they have time to fix bugs. It is then simply assumed that the team will spend a certain amount of time each sprint fixing Jira- reported bugs
- Put the product backlog in Jira (i.e. ditch Excel). Treat bugs just like any other story.
If the product owner lacks the judgement, we may need to follow the option 3 or option 2, otherwise, putting the prioritization on the Product Owner is still the best approach as long as we have a right product manager that has the functional knowledge as well as the good sense about product quality.
Having a separate PQE team (or Sustain Engineering team) may be necessary if we are introducing a big project and we would like the team to have the focus, especially when the new product features are time bounded due to the customer commitment or time-to-market requirements from marketing perspective. Only if the resource pool is separate, option 3 makes sense.
The prioritization of bugs should not be based on # of customer issues raised in the support ticket. This type of thinking is putting the company at risk since it encouraging escalations. It should be based on whether a workaround is available and whether the broken area is on a critical process flow. If yes, even one customer is raising the issue is a high priority as it may be the first one, but not the last one.
No comments:
Post a Comment