Story pointing is generally done to have a good idea for our release planning and see how much we can commit to the customer
Bugs can fall into one of the following category
So should we story point the bugs which fall in any of these categories? Not really
We can strategize in different ways to handle the bugs.
Case 1
Let’s say we have a feature and its story pointed also our definition of DONE means: Feature should be completed without any bugs in it. In this case the bugs that are falling in the Category 1 (i.e. Bugs in the current sprint) should be completed in the current sprint itself and we should not story point the bugs separately since we have already story pointed the feature. Again story pointing the bug will give a false velocity of the team.
Case 2
For example we have a feature that is already completed in the previous sprints let’s say SPRINT 1 and we have marked it as DONE. Say we are in SPRINT 3 and found any issue with the feature that was marked as DONE in SPRINT 1. How are we going to handle that?
These types of scenario falls under the Category 2(: Bugs from the previous sprints)
We can use the following strategies.
a) We can ask the PO to review the bug and see how important that is .Accordingly can request him to prioritize and take that up in the next sprint depending on the priority. If it’s a high priority issue , team can story point the bug or we can follow the next approach i.e.
b) During our sprint planning we can allocate some amount of time from our actual velocity for handling Category 2 bugs so that we need not story point for them.
For example our total velocity for the sprint is 100hrs; we can allocate say 10% for bugs from the previous sprint so 10hrs will be blocked for any issues coming from the previous sprint.
Note that these hours should not be fixed, if there are no bugs coming from the previous sprints then it should be used for feature development.
Case 3:
There might be issues coming from the field. This issue should be routed through PO.
PO will be deciding how important the bug is and he will decide whether it should it be taken as a bug or should it come as a new feature.
If we are taking it as a bug then what every point mentioned in Case 2 will be applicable.
And if it is coming as a feature then we will story point them.
The bottom line is PO and Team should discuss, agree and come up with a strategy that can be best used to tackle any type of bugs.
Bugs can fall into one of the following category
• Category 1: Bugs in the current sprint
• Category 2: Bugs from the previous sprints
• Category 3: Bugs from the field.
So should we story point the bugs which fall in any of these categories? Not really
We can strategize in different ways to handle the bugs.
Case 1
Let’s say we have a feature and its story pointed also our definition of DONE means: Feature should be completed without any bugs in it. In this case the bugs that are falling in the Category 1 (i.e. Bugs in the current sprint) should be completed in the current sprint itself and we should not story point the bugs separately since we have already story pointed the feature. Again story pointing the bug will give a false velocity of the team.
Case 2
For example we have a feature that is already completed in the previous sprints let’s say SPRINT 1 and we have marked it as DONE. Say we are in SPRINT 3 and found any issue with the feature that was marked as DONE in SPRINT 1. How are we going to handle that?
These types of scenario falls under the Category 2(: Bugs from the previous sprints)
We can use the following strategies.
a) We can ask the PO to review the bug and see how important that is .Accordingly can request him to prioritize and take that up in the next sprint depending on the priority. If it’s a high priority issue , team can story point the bug or we can follow the next approach i.e.
b) During our sprint planning we can allocate some amount of time from our actual velocity for handling Category 2 bugs so that we need not story point for them.
For example our total velocity for the sprint is 100hrs; we can allocate say 10% for bugs from the previous sprint so 10hrs will be blocked for any issues coming from the previous sprint.
Note that these hours should not be fixed, if there are no bugs coming from the previous sprints then it should be used for feature development.
Case 3:
There might be issues coming from the field. This issue should be routed through PO.
PO will be deciding how important the bug is and he will decide whether it should it be taken as a bug or should it come as a new feature.
If we are taking it as a bug then what every point mentioned in Case 2 will be applicable.
And if it is coming as a feature then we will story point them.
The bottom line is PO and Team should discuss, agree and come up with a strategy that can be best used to tackle any type of bugs.
2 comments:
Is it a rule or have you just stated your experience?
There is no specific rule in the agile process. We should try to adopt what ever is good for the team.
Post a Comment