What is Scope?
In life, it's evident that everything should have a limit. Even when it comes to a project, it's the same baseline rule that applies. The scope is the breadth of work that will entail in a project or in a certain phase of a project.
Why is it required?
This is required so that all the stakeholders reach a common understanding of what is included in the project and what is not.
It is important to keep the scope defined and duly documented to ensure there are no complications.
So, what is a scope creep?
Scope creep is the uncontrolled changes to the scope of the project. These changes could be features or functions that are not agreed upon.
Now, pay good attention to the word 'uncontrolled''. If the scope goes out of hand, the project wastes money, decreases satisfaction, and makes it nearly impossible to meet the end goals.
It is important to have clarity on your scope. For starters, document your scope.
Why does scope creep happen?
- Lack of clarity and depth of scope documentation
It is good to have a decomposed scope (preferably in a work breakdown structure) to ensure that everyone is in common consensus.
- Rushing into development with no planning
Different external factors could make product owners rush into development with no planning or forward thing. It is only halfway towards the development, that they figure out they have missed something important.
- Conflicts between the stakeholders
If all the relevant parties were not in requirement elicitation meetings or any other meeting where their presence was required, scope creep is something that you may experience. Hence, it is important to know your stakeholders and where they are required.
- Requirements being added without context
Requirements should always align with the project goals and objectives. Hence, at the start of the project, lay out the project's objectives. Align every user story, feature, or requirement to drive the project objectives.
How to avoid scope creep?
With the changing world, change is inevitable. The whole reason why the Agile concepts are picking up pace in modern times is to facilitate changing requirements.
In order to prevent scope creep, simply avoid doing what causes it (as mentioned above). In addition to this, the following tips might come in handy!
- Scope changes should follow a process.
Regardless of whether it is Scrum or Waterfall that is followed, there is a basic set of underlying principles to live by.
For e.g.: When it comes to Scrum, it is important to not change the agreed set of work for the sprint. In other words, stick to the sprint backlog once committed at the sprint commencement.
- Don't try to Gold-Plate.
Do just enough. Don't spend too much time making things too perfect. Commit to delivering what is expected.
Scope creep in Waterfall
In the waterfall software development methodology, a rigorous agreement is made on the requirements. A software project that follows the waterfall methodology will have all the nitty-gritty of the entire project neatly documented prior to development. Hence, if scope change is required, there is a whole predefined "Change Control" process that has to be followed.
This often means conducting several meetings where the authorized stakeholders take part, as defined in the terms. The said meetings will often involve a painful process of negotiations to come into common terms. Once, everyone reaches a common understanding, the scope change requests are neatly chronicled, requirement documents are updated to new versions, alterations to time & cost is made and signed off by relevant parties.
Scope creep in Agile
In agile, change is accommodated. Agile adds new scope.
However, once you are in a sprint or an iteration, there can be no changes to the initially agreed backlog of work for the said sprint or iteration. This is the reason why agile teams plan the sprints or iterations for short periods of times such as a week or two.
Now here's something to remember. In agile terms, it is not scope creep if the change does not create additional work for anyone. In other terms, if nobody has given any previous thought or worked on the task that requires change, there is no harm in this change.
If in case your stakeholders want you to swap already committed or delivered work with new ones, or if they want a change in it while development is progressing, this is considered scope creep.
So, how would you go about controlling scope creep in agile?
If you are following agile methodologies, your team tracks the tasks you complete in every iteration or sprint. When you begin your iteration, you have committed to a backlog of work to deliver on the said date. Hence, new work should only be introduced during planning before the start of the sprint. So, it is simple as this - if someone alters the task once it is estimated and committed to, they need to understand that this will adversely affect the sprint goal and the sprint delivery. The team will most likely not be able to meet the goal by the sprint end.
Okay. This is not an ideal world. There had been times where me and my team had to attend to urgent incidents in the middle of a sprint. So, here we do a trade-off. If we are to attend to some other unforeseen, urgent task, the effect this will have on the sprint will be understood by all parties.
Although this is not encouraged, this happens in the real world. So, we can anticipate such problems early on and come up with a strategy to smoothen things out.
Comments
Post a Comment