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.




2017-03-31T06:20:02+00:00 Categories: Agile, Project Management|

About the Author:

Elizabeth joined CivicActions in 2010 as an Agile Project Manager, leading teams of developers and designers through successful digital projects for nonproft and government clients. Her impeccable attention to quality and enthusiasm for human connection propelled her to become Director of Professional Services in 2014. In this role, she oversees hiring, business development, team leadership, client relationships, and thousands of small details per day — all while helping team members remain present and productive.

Elizabeth excels at facilitating change, encouraging growth, and empowering people. She brings an aura of confidence and balance to even the most complicated projects, inspiring her teams to problem-solve and collaborate until victory is achieved. She has served on a myriad of projects for CivicActions clients such as the Department of Defense, the City of Los Angeles, C2ES, Denver Public Library, EatFresh (San Francisco Human Services Agency), FosterClub, GlobalMDP Program (Columbia University), Netpop, and SACNAS.

As a certified ScrumMaster, Elizabeth is passionate about spreading the positive impact of agile project management in public sector organizations. She helped establish and expand Agile Government Leadership (AGL), a community powered network of agile professionals working to increase user-centered, iterative processes in government. She collaborates with the AGL working group to provide resources, arrange partnerships, host events, and facilitate conversation so agencies can be empowered to start using agile methods. Elizabeth has also moderated and spoken at a number of events across the country on the topic of agile government.

Before joining CivicActions, Elizabeth served as Director of Project Management for the software company Casting Networks, where she helped form the PM and QA groups, along with introducing and implementing agile methodologies.

Elizabeth holds a BFA from Wayne State University and lives in the Bay Area with her husband and young daughter. She appreciates the flexibility of working full time from home, hanging out with her kiddo during lunch breaks, and practicing yoga for mental balance and physical health. Elizabeth also enjoys reading the funnier side of the internet or getting outside with her family — being in California, this means the beach and the mountains.