Deprioritize story from sprint backlog

Last post 01:45 pm April 22, 2021
by Manish Rai
7 replies
Author
Messages
03:00 pm April 19, 2021

Hi All,

What would be the best approach for Scrum Master, in case the team is in the last week of sprint and it is identified that 2 of the team members went on sick leave and won't return until the sprint end.

Other team members won't have the bandwidth to take over those impacted stories. PO is highlighted regarding this impediment. Would it be good to deprioritize those stories as those could not be completed in the current sprint?

07:38 pm April 19, 2021

I believe that the Developers and PO should discuss the situation in order to re-negotiate the sprint backlog without jepardising the sprint goal. 

07:43 pm April 19, 2021

It depends on what you mean by "deprioritize".

The first thing I'd suggest looking at is the Sprint Goal. If this work is not completed, what is the impact on the Sprint Goal? If there's no impact, then I wouldn't be too concerned. The work is a forecast and there's always things that can emerge as the Sprint happens, with team members being unexpectedly unavailable as one thing that could emerge. However, if the Sprint Goal is in jeopardy, the team (including the Product Owner) should work together to maximize the chances that the goal is achieved.

However, if you're just talking about how work is allocated to Sprints in whatever tools you use, I wouldn't worry about that at all. It's OK that some work isn't done in a Sprint. I'd even say that having the work as planned and then unfinished (or even unstarted) can be a good discussion point in the Sprint Review or Sprint Retrospective. Pretending that the work wasn't part of the Sprint or hiding this doesn't help openness and transparency.

10:13 pm April 19, 2021

What would be the best approach for Scrum Master, 

Per the Scrum Guide this isn't anything that the Scrum Master would be involved with.  This would be a discussion between the Product Owner and the Developers to determine what should occur. Based upon your description the only part missing is for the Product Owner and Developers to agree on what action to take.  You could raise that awareness to the team.  But you should not be doing any of the prioritization or changes to the Sprint Backlog.  That is for the Developers to do with input from the Product Owner.

In real life, the Scrum Master is probably going to schedule time on the Product Owner and Developer's calendars for a meeting to discuss it.  Then after they make a decision, you will end up making the updates to the Sprint Backlog and commenting on all of the items because no one else "has the time to do it".  

(where is the facepalm emoji when you need it?) 

 

04:07 am April 20, 2021

What would be the best approach for Scrum Master, in case the team is in the last week of sprint and it is identified that 2 of the team members went on sick leave and won't return until the sprint end.

How has risk been managed by the team throughout the Sprint? Perhaps enough work has already been Done for the Sprint Goal commitment to be met. I'd suggest that the best approach for a Scrum Master is to foster transparency over such things.

05:44 am April 20, 2021

Thank you, Scott AnthonyThomas OwensDaniel Wilhite, and Ian Mitchell for your inputs, I truly appreciate it.

Daniel, as SM, I have highlighted the impediment in attention to PO and Dev team. In that discussion, PO confirmed that she is good if dev team unable to complete these stories in the current sprint and roll over to the next sprint.

But, instead of rolling over shouldn't be deprioritized from the current sprint and move to backlog if no dev team member could complete the work?

07:40 pm April 20, 2021

There isnt any harm in keeping them in the sprint, just in case the Developers do have time to work on them. 

Remember, that any PBI that has not met the DoD by the time the sprint timebox has expired, will be re-estimated and then placed back into the PB for possible future sprint selection. 

01:45 pm April 22, 2021

Thank you, Scott !!