Patch requests have started piling up in the form of Product backlog items (PBIs) in developer team Product backlogs. Some developer teams have a new sprint starting out soon so incorporating these new PBIs into new Sprint is easy. However some developer teams have just started sprinting; what do we do now:
a) Make customers wait to get their patches until the next Sprint in 2+ weeks so we can follow our Scrum development process rules
b) Close one eye and make a small exception within the Scrum rules, add the new PBIs to existing sprint
The answer is c) neither of the above - we need to both get patches to the customers in a timely manner and not violate the Scrum rules. Here's how...
Case 1: A new developer team Sprint is about to start in under a week's time
The answer is simple - just get the new patch request PBIs approved and prioritized on time by your Product owner and incorporate it in the new Sprint
Case 2: A new Sprint has just started and it will be another 2 weeks until it is finished; approved PBI requires a patch containing High severity bug fixes only
This means that the patch will take up to 3 weeks to be finished but it will be ok as none of the defects are Critical severity in the first place
Also use common sense - if you have 2 simple High severity defects to patch which would take a few hours of ad-hoc time, do so now and don't let it linger on for weeks
Case 3: A new Sprint has just started; approved patch requesting PBI contains Critical severity bug fixes that can't wait for the next Sprint
Pause the work on your Sprint and get this patch done ASAP; you already have allocated ad-hoc time for such work outside of the Sprint time
Ad-hoc working Q/A
Q: I've spent my 2 hours of allocated ad-hoc dev time for today; should I go back to my Sprint tasks even though Critical severity bugs patch isn't finished?
A: No - focus on completing one goal at a time; this means you should work whole day if needed to get that ad-hoc patch PBI wrapped up before going back to the Sprint tasks
Q: We're starting work on ad-hoc PBI - do we need to define individual tasks in the team and possibly make a separate Sprint for this, then sprint two Sprints in parallel?
A: Don't introduce complexity when there is none. The reality is you are working on 2-3 ad-hoc bug fixes to get the patch ready; these should show up as Bug fixing tasks in your Daily status report, i.e. "PBI #12345 - Create patch for Refactor 2012 R1 with 2 bug fixes; TFS #8943 - High - Bug name"
Q: I'm going to work on a Saturday, but should I focus on my ad-hoc tasks since weekends aren't calculated in the Sprint time?
A: Assume that working weekends or holidays are just like any other working day and take your priorities in order. Sprint comes first unless there are higher priority ad-hoc tasks such as a patch requesting PBI for Critical severity bugs
No comments:
Post a Comment