The Creepy Scope

 

We are all familiar with scope creep and how if left unchecked it can consume a project pretty rapidly. Depending at what stage of the project we are in when the scope starts to get out of hand, our risk contingencies and planned responses may be too little too late.

In the Scrum world, a major source of scope creep are the items that find their way into the Sprint Backlog and sometimes bypass the Product Backlog refinement process altogether.

Here are three ways the dreaded creepy scope can make their way into the Sprint Backlog and threaten the stability of the Scrum adoption within an organization:

1. Sprint Hijacker
In most organizations there are some very influential stakeholders or customers that don't mind bypassing protocol to get what they want. In fact, it is partly why they are so successful. These individuals want their feature included in the current Sprint and jumping the queue in order to do that is just collateral damage.

Some team members may even develop a rapport with the Sprint hijacker and let some features in, making it more a case of Stokholm Sydnrome than positive feelings toward the hijacker. In these circumstances, both the Product Owner and the Scrum Master need to step in.

The Product Owner needs to consult with the stakeholder to ensure that any requests for "urgent" features find their way into the Product Backlog, and then refined and prioritized along with all the other items. The Scrum Master must shield the development team from any external distractions which reduce their performance or jeopardize the Sprint Goal. The Sprint Hijacker is one of these external distractions.

2. The Boy who cried Wolf
If the Product Owner is not on his/her game, or they are less than honest, they may create an oversupply of Must Have's that should be Should Have's, Should Have's that should be Could Have's, and Could Have's that should be Won't Have's to enter the Product Backlog.

Incorrect prioritization gives a false impression that some features are more important than they really are. When the Product Owner allows this to happen, the Development Team soon gets wind of the boy who cried wolf and this can cause them to lose trust in the prioritization process and the Product Owner. The Development Team may then compensate by adjusting their estimates, or worse still, treat a feature as anything less than a Must Have.

If this is done enough times, the product becomes a very different beast. The key here is to ensure honesty, integrity and transparency in the Product Backlog refinement and prioritization process.

3. GPDoD
I had to fit an acronym in somewhere. GPDoD is my acronym for Gold Plating the Definition of Done. Oh yes it happens. The Definition of Done (DoD) within a Scrum Team is a "shared understanding of what it means for work to be complete, to ensure transparency". As the project progresses, the DoD can change, become more detailed, and require more steps. It is basically a checklist to ensure that everything the team said would be done, is done, and the feature/increment is potentially shippable.

But that's when everything goes right. It can also go terribly wrong. Most of us know what gold plating is. While this is a term we normally associate with waterfall projects, they can still infect Scrum projects even with a rock-solid DoD.

Gold plating can happen through a number of ways: a relationship with a customer or stakeholder that includes some bells and whistles that are not required, an enthusiastic developer who just wants to increase customer satisfaction, misunderstanding of the customer's requirements, miscommunication with the Product Owner, and the list goes on.

This phenomenon is not only limited to the features we and the customer see. Gold plating can also manifest itself down at the code level where da Vinci developers want to tweak the code beyond what is required to meet the DoD, simply because it is aesthetically pleasing to their idea of good code writing.

                                                                * * *

If you are concerned that the creepy scope may visit your Scrum neighborhood, my advice is to grab a large poster and pin it on the wall with large block letters quoting:

"Done means Done. Not Done and then Some!"


References
Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from: www.scrumguides.org

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!