How Development Team should manage adhoc requirements that are coming from PO during every Sprint?
There are situations wherein there are request from Product Owner to take up some adhoc business requests which can't even wait until n ext sprint. This generally happens while working in Healthcare products and there are compliance related requirements which has to go to production within next few days.
Per Scrum Guide, any new Product Backlog Item /requirement should be added to Product Backlog and Product Owner decides the priority of the Product Backlog Item. She either add it as a priority Product Backlog Item for the upcoming Sprint or move it to later Sprints. But, what if Product Owner herself is coming up with adhoc request in mid of Sprint and this is happening almost every Sprint?
Best way to handle this situation will be to keep some buffer time for the Development Team during the Sprint Planning to work on these adhoc requirements. Scrum Team can empirically decide how much adhoc work they are generally getting each Sprint and allocate approx. 10-20% of their total capacity to work on these adhoc work. Development Team should spent r est of the time on planned work to meet the Sprint Goal.
Best way to handle this situation will be to keep some buffer time for the Development Team during the Sprint Planning to work on these adhoc requirements.
Why do you think that is the best way? What alternatives have you considered?
Hi Ian,
Other alternative can be to keep 1 or 2 members from the development team to dedicatedly work on the adhoc requirements. Please suggest if there is any other better way to handle this.
Thanks,
Bhanu
One alternative approach is to plan a certain amount of work into the Sprint Backlog which, while enhancing the value provided, is not absolutely critical to the Sprint Goal.
This allows for scope to flex in response to unforeseen events of various kinds. Unessential work can be traded out of scope while the Goal itself remains achievable and intact. In effect scope may be used as a buffer rather than a block of time.
No-one can force work onto a Development Team. If the Product Owner requests for an unplanned, urgent, and critical piece of work be actioned, but there is insufficient work for the team to trade out of scope while preserving the committed Goal, then the value of continuing with the Sprint may have to be reconsidered.
Another approach can be to support different qualities of service for different types of work. A team may provide transparency (e.g. an expedite lane on a team board) over unplanned urgent items. When expedition is requested, such as for a critical issue, the team will decide whether or not existing work can be replanned to accommodate it without compromising the Goal. Informed decisions about the viability of the Sprint can then be made accordingly.
Thanks Ian for sharing your thoughts. Your explanation helps!