An I.T. Executive Question:
At a recent executive presentation, the question was asked: How do I handle Scope Creep in a Sprint?
My Answer:
Within a sprint, there should never be any creep. I control it this way. In the Sprint Planning session, the team “commits”, based on their velocity, to what they can complete in that sprint. The mantra for my teams is this, “They must deliver user acceptance tested software every sprint.” If we cannot deliver I will cancel the sprint. This has only happened once in my 16 years as an Agile Transformation Specialist.
I put here at this point, one of the famous quotes from Jeff Sutherland, co-founder of Scrum; “Any Scrum without working product at the end of a sprint is a failed Scrum.” I believe that says it all. You must produce working software at the end of every sprint.
Now, if during the sprint, the Product Owner realizes, that something was forgotten in the Acceptance Criteria, or a new feature within the functionality was missed and now discovered, that is what we actually want to see happen. That is the essence of Agile. That “plus” or “delta” is now written as a new User Story, estimated by the team and placed in the Product Backlog, not the Sprint Backlog. I will not allow my teams to be overcommitted. Now if they get ahead of the “curve”, they can “pull” it into the sprint.
Remember, as Jeff Sutherland, continually tells us, Scrum is a “pull” system, not a “push” system. No one can “push” anything onto the team. It is up to the team to pull off the backlog the PBI’s (Product Backlog Items) they feel they can commit to completing in the sprint. It is the team that makes the decision since this is their commitment. Not management or stakeholders. Now, if the “plus” or “delta” is critical for this sprint, then the Product owner, must pull something out of the sprint backlog that equals the story point value of what is added. Again, I will never allow my teams to over-commit so that we always meet our commitment to the stakeholders. Finally, if this cannot be done, then I will cancel the sprint. Otherwise, we are back on the “slippery slope” that has created failure after failure for us in I.T. over the decades. It always works for me.
As a final comment, I tell my students this. This is not scope “creep” but required business change. In Agile we are all about adapting to business change.
Just my way of being successful. In 16 years I have not had one failure. But, this requires immense discipline, and as Both Jeff and Ken, co-founders of Scrum tell us continually, in most agile failures, lack of discipline is the cause.
And what is the cause of this? “Lack Of Leadership. Agile Leadership.” We will cover this in future posts!
We are agile.
Author: Ed Rubuliak
Web Site: https://theagilemasteryacademy.com
email: ed.the.scrum,professor@gmail.com
Facebook Group: https://www.facebook.com/groups/3226848237379645/
Facebook Page: https://www.facebook.com/Agile-Software-Development-482874298764658/
