Skip to main content

How Development Team should manage adhoc requirements that are coming from PO during every Sprint?

Last post 04:53 am September 23, 2018 by BHANU PRATAP
4 replies
05:39 pm September 21, 2018

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. 

 


06:33 pm September 21, 2018

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?


04:05 am September 22, 2018

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

 


07:26 am September 22, 2018

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.


04:53 am September 23, 2018

Thanks Ian for sharing your thoughts. Your explanation helps!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.