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.
Elizabeth Raley joined CivicActions in 2010 as an Agile Project Manager and Quality Assurance guru.