Scrum Rule: No Additional Requirements Can Be Added to a Sprint!

Elizabeth Raley Profile Photo
Elizabeth Raley

on

September 7, 2011

Scrum Rule: No Additional Requirements Can Be Added to a Sprint!

 

The rules of Scrum are simple and complete, but it's easy to stray from the plan that Scrum has so clearly laid out. Part of the role of a ScrumMaster is to teach and coach on Scrum - and make sure that the framework is being followed.  It's simple but not easy. There is always the temptation to go back to old habits and make exceptions to the rules. 

A common challenge occurs when the Product Owner wants to add to the sprint. So we'll start here with this rule of Scrum: Once a sprint begins, you cannot add requirements or stories to the backlog

This is a rule because in order for Scrum to work, we need to have our time boxes and our sprint backlog. The sprint backlog is the agreed upon amount of work to be completed in the sprint, in the form of specific requirements that have been estimated. The time box is the amount of time that we have agreed to the sprint - 2-4 weeks. 

Scrum makes it easy to react to changing business needs. At the beginning of each sprint the Product Owner requests that we work on the highest priorities first and in turn we deliver the most value up front. So what do you do when you are one week into a four week sprint and your Product Owner tells you she forgot to add a ticket regarding a critical piece of functionality? 

Well in order to follow Scrum, you tell her to put it in the backlog and she can prioritize this for the next sprint. Your product Owner may argue that it can't wait, and that she would gladly trade two other tasks for this one task. It sounds tempting because not only do you want to appease your Product Owner, but you also see the value of this new requirement. But here's the issue: the team has not even seen this new requirement, it's not been estimated, it's missing the critical exercise during the Sprint Planning meeting, where we can ask questions and make suggestions. Even adding the smallest ticket derails the team, the velocity shifts and since these rules are in place, the integrity of the process also diminishes. 

But what if this proposed new requirement MUST be done immediately? Then you stop the sprint and you address this new emergency; have a Sprint Planning meeting and start over! This means that the sprint you were working on is over and anything that was in that sprint returns to the Product Backlog. In most cases this won't happen, the new requirement isn't critical enough for the Product Owner to agree to stop the sprint, but it happens and this is the solution. 

I'm curious what other challenges the readers have faced with following Scrum instead of falling back into old habits. Please share in the comments section below!

This is the sixth in a series of posts about Scrum. For the first, please see The Three Elements Of Scrum.


 

 

 

Share it!

Understandably, we are not able to add new stories to a sprint (unless the team has completed current commitments), howevere I would be interested in your thoughts on handling support requests for current functionality?In our environment, we have a tight support arrangement with our clients, with very high uptime requirements. Our current solution is to have a "support" story for each sprint to track critical support tasks that come into the team each sprint, but I would live to hear how other teams look at this. cheersPete
 Hi Pete - great question! Support is something that many teams deal with in day-to-day client management. The advice that I have gotten in the past is to have a team who focuses on maintenance, so that it doesn't derail the project team. In reality this cannot always happen for reasons of budget, project knowledge, time restraints, etc.  In my project team, we usually have a few hours a week set aside so that if emergency requests (WSOD) come up, we can respond in a timely fashion. If it's not an emergency, we try to group maintenance requests together so that we can plan for a short sprint in the near future to address these requests.   In your case, it sounds like you are handling it well by adding support stories to each sprint. Either you already know what these stories are because they came up before the sprint started, or you are creating blanket stories that allow you to react to emergencies that arise during a sprint. If this is working for you, I'd say keep going with it. If not, then consider a maintenance team or a maintenance sprint between sprints.