Skip to main content

sprint backlog change

Last post 04:59 pm July 9, 2018 by Syed Armaghan Hassan
3 replies
10:20 am May 30, 2018

Hi All,

I have a situation in our current sprint. Due to some emergency, one of the new resources who was assigned a story in the current sprint will not be able to complete due to her unavailability for the rest of the sprint. 

The PO is already aware of the situation and is ok to pull the story out of the backlog and agrees to get it picked in the next sprint that kicks off in a couple of days.

As a scrum master, i need to know, can i go ahead and make the change or does this mean that the sprint has failed?

Thanks

 


10:49 am May 30, 2018

As Scrum Master, why do you feel that it is your right to change the Sprint Backlog?  Only the Development Team has that privilege.

Why is work 'assigned' to an individual?  Shouldn't the entire Development Team be accountable for delivery of the Sprint Goal? 

If the 'story' is pulled, how does this impact the Sprint Goal?

Shouldn't the Scrum Team collaborate with stakeholders in the Sprint Review to decide what to work on next Sprint and adapt the Product Backlog, after inspecting the Increment?  

My suggestion: read the Scrum Guide as it provides all of the above answers for you.  What you will find is that if the Development Team forecasts too much work, they may renegotiate scope with the Product Owner, as long as the Sprint Goal is not impacted.  The reason why we have Sprint Goal in the first place is to provide guidance and flexibility.


11:30 am May 30, 2018

Does the team have a Sprint Goal at all, towards which work on the Sprint Backlog is forecast and replanned?

If so - with only two days left in the Sprint - why is the probability of success unclear to team members?


08:50 am July 8, 2018

Hi Chris and Ian,

 

thanks for the guidance you have been providing. 

The most controversial question in my head at the moment is, "Who changes the sprint-backlog"?

Of course the Dev.Team is owner of iSprint-BL and has the privilege/right to change it, but only when it comes to change the 'Plan' about how are they going to achieve the sprint goals, and what tasks do they need to modify/re-plan etc., right? 

However, the Spring-BL is not just the plan, but also the Features/Items/Stories which the Dev.Team chose earlier at their disposal in agreement with the PO, correct? This means, that the Sprint Goal was decided earlier by PO (I guess), and Stories/Items were chosen by Dev. Team based on their estimated capacity to deliver the increment. These item(s), which are the second part of the definition of Sprint-Backlog (chosen from PBL and is an output of Sprint-planning-Meeting), must now be delivered by Dev.Team to achieve the Sprint-Goal. 

The question is, if the Dev. Team wants to add/drop items/stories based on more/less capacity, are they entitled to do it without the authorization or agreement of PO? 

I did  find the answer in Scrum-Guide, however, I am not sure if like they are just talking about the plan or also the user-stories/Items which can be changed at the discretion of Dev. Team? IT is driving me crazy as I have to give an exam today in a couple of hours. Although I do not expect such a quick response on Sunday, however, in case someone is out there listening, a 100% authentic answer in compliance with scrum guide will be immensely appreciated!

 

Thank you guys!

Respect for everyone, Armaghan.


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.