Skip to main content

Changing of capacity during the sprint

Last post 09:39 pm February 14, 2019 by Daniel Wilhite
4 replies
10:58 am February 6, 2019

Hello everybody, I am the Scrum Master of a small team of 4 dev (including me) + P.O.

My question is: how to deal with a change of capacity during the current sprint?

E.g.: if something unexpected come up for a team member and he has to leave for 3/4 days (the sprint length is 2 weeks), what is the best thing to do? Would it be correct to set-up a meeting to review the scope of the sprint?

And what if the changing of capacity is small, like 1 or 2 days ? Maybe a provisioning of 1 day for each team member shall be counted when planning capacity?

Thank you,

best regards

Diego


05:03 pm February 6, 2019

Just my personal opinion, but I would try to avoid "padding" a sprint backlog with potential capacity concerns that may or may not pan out.

Scrum allows you to use scope to adjust the sprint backlog as needed due to capacity changes or other unforeseen events.   In addition, the Scrum Team has a daily inspect and adapt ceremony (Daily Scrum) to evaluate the health of the sprint and adjust if needed.

My suggestion would be to not only leverage these two strategies that are available to mitigate situations just like this, but to also "take it to the team", and gauge what everyone else feels about the unexpected loss of capacity.


05:31 pm February 6, 2019

My question is: how to deal with a change of capacity during the current sprint?

E.g.: if something unexpected come up for a team member and he has to leave for 3/4 days (the sprint length is 2 weeks), what is the best thing to do? Would it be correct to set-up a meeting to review the scope of the sprint?

Is it clear to the Development Team at all times whether or not the Sprint Goal is achievable?


05:45 pm February 14, 2019

Hi Timothy and Ian,

thank you both for your replies.

@Timothy: so as far as I have understood from your reply, the idea is to adjust the sprint backlog as needed, but this may lead to a changing of the sprint goal, or better to a "resize" of the sprint goal, isn't that un unlikely situation?

@Ian: yes, it is


09:39 pm February 14, 2019

Scrum, and Agile in general, are built upon empiricism.  Empiricism is the art of making decisions based on the information you have right now.  

Plan based on what you know for sure at the time of the planning event.  If some new information is acquired (i.e. someone's appendix burst and will be out for 3 weeks), then inspect it and adapt. When would all this occur?  There is an event that is designed for this and it occurs on a daily basis for 15 minutes or less.  If the Development Team feels that the situation endangers the Sprint Goal the conversations become different and longer in what ever form is necessary. If the Development Team does not think it will impact the Sprint Goal, then carry on. 

Don't make it more difficult than it is.  Just because something happens doesn't mean that it requires drastic measures. 


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.