Skip to main content

Question regarding reserving capacity

Last post 10:19 am December 23, 2022 by Abayomi Joseph Ajayi
8 replies
04:20 pm September 6, 2022

Hi, can anyone explain to me this.

 

Teams should not reserve any of their Sprint capacity for unplanned work?

i believed this to be true but I had it wrong. I was wondering if someone can clarify


04:59 pm September 6, 2022

Who made this statement, where, and in what context? It's inconsistent with what I would consider to be a good practice for teams.


05:48 pm September 6, 2022

Hi, can anyone explain to me this.
 

Teams should not reserve any of their Sprint capacity for unplanned work?

i believed this to be true but I had it wrong. I was wondering if someone can clarify

Is there a belief that this policy will stop unplanned work from then happening? A good Scrum practitioner is unlikely to put much faith in this strange magic.


06:11 pm September 6, 2022

Teams should not reserve any of their Sprint capacity for unplanned work?

If that were true, then Developers would not be able to work on anything that they discovered while doing the work they included in the Sprint Backlog.  That would be "unplanned work". And what exactly is "Sprint capacity"?  How would that be measured, especially to such an exacting nature as this question implies? 

If you got this question from some source you are using to test your knowledge of Scrum, I would suggest you leave that site and never go back.  It does not instill any faith in me that the source truly understands Scrum. 

But since you asked about this, I'll elaborate a little. A Sprint is planned to complete the Sprint Goal and deliver a usable increment of quality work for a Product.  There is nothing that says all the work done by the Developers during that time has to be for that purpose. However, if anything will prevent the Developers from completing the goal and increment, it should be considered an impediment and dealt with.  If the work is discovered to be more difficult or involved than expected at planning, conversations ensue to arrive at a compromise or solution. 

Sprints are not planned based upon a set capacity. A Sprint is not planned so that every Developer has exactly 8 hours of work every day.  Unless, the Developers want to do that and are capable of doing so, however I have never seen a team of Developers that desired to or were capable of it. Sprints are planned to deliver incremental value with a specific Sprint Goal in mind. 

 


11:43 pm September 6, 2022

I apologize for the lack of context. It from a practice test sample for the PSK 1


11:49 pm September 6, 2022

I apologize for the lack of context. It from a practice test sample for the PSK 1

Perhaps I'm not understanding the question and correct answer, but if the sample test was suggesting that teams should not reserve any of their Sprint capacity for unplanned work, I would question the rest of that sample test as well.

I think it's accepted that teams should be reserving some capacity within their Sprint for unplanned work, or more generally, unplanned events. Unplanned events take on many forms. There could be work needed to get a Product Backlog Item to done that was unplanned at the start of the Sprint. There could be urgent and time-sensitive issues that arise that the team needs to address. Someone could be unavailable, such as unplanned sick leave.

Agility is about responding to change and uncertainty instead of following a plan. Planning a Sprint to full capacity means that the team has no way to handle unplanned work being discovered without replanning their goals.


11:52 pm September 6, 2022

Thank you. 


11:03 pm December 20, 2022

I believe this was taken out from : You don't have to plan for all your capacity in Sprint Planning - you can have some reserved capacity for unplanned work. It's not mandatory to have reserved capacity, nor is it mandatory to avoid it; it's entirely up to you.

It is only one word, "should". With this, educational provider said that the previous statement is "False"

It is not mandatory to have reserved capacity (it doesn't say so in Scrum Guide or Kanban Guide for Scrum). 


10:19 am December 23, 2022

There are so many uncertainties inherent to the process of software development and the developers have a responsibility to fix bugs. 

Consider a situation where in the middle of a sprint, a user reports a bug for a recently released feature and if this is not fixed ASAP,  it will not only affect operations but also an inclusion in the Product Backlog. 

Would it not be appropriate for a contingency; thus reserving some capacity within their Sprint for unplanned work?

@Dragan "It is not mandatory to have reserved capacity (it doesn't say so in Scrum Guide or Kanban Guide for Scrum) "  

Agreed however, Scrum is not prescriptive, the team must always do what is the best interest of the organization,  Agile Principle 1 is to priortize customer satisfaction, you can extend that thus; would it not be a strategic approach  to have a reserved capacity in the event of uncertainty that might affect customer satisfaction? Furthermore, as an extract from the Scrum Guide "Various processes, techniques and methods can be employed within the framework". How good is that!


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.