According to Ken Schwaber (co-creator of Scrum), one of the key principles by which Scrum is guided is “A team can deliver the most valuable software within a prescribed time and budget, and yet a team cannot definitively predict the exact functionality of what will be delivered”. Scrum framework considers scope as a leveraging tool, or a potential buffer that can be used to accomplish certain business goals.
E.g. If we are late, we can potentially cut a less important requirement. This is an option because, according to Scrum, from the very beginning we should be focused on developing the most important requirements. Equally, if a new important requirement occurs during the development, the Product Owner can choose to replace a less important one with that new one, within the Product Backlog. (This was already mentioned in one of the previous articles – read more)
It is essential that a single person is the final authority when it comes to the Product Backlog and its management and prioritization. In Scrum this person is called the Product Owner. Although there could often be many stakeholders (customers, end users, managers, architects, etc.), a Product Owner is responsible for representing them all. Usually a Product Owner has a very difficult job of understanding requirements’ priorities from a customer’s point of view. Generally, customers would say that everything is a must have. Product owner’s job is to rethink what will bring the greatest value to a project and a customer, and to put these requirements at the top of the priorities list. In software development, there is a rule (based on many researches), that 20% of features brings 80% of the value. Prioritizing by value will “force” a team to produce these 20% of features that will create the highest ROI. After the implementation of these features, in most cases comes up the question do we really need another 80% of features, or are they still as important as they were at the beginning of a project.
There are different techniques for prioritizing the Product Backlog based on business values: MoSCoW, Kano Model, Relative weighting, WSJF, etc. During a Product Backlog prioritisation, a Product Owner should take into consideration other factors besides business value – things like costs (estimation), domain knowledge, technology, risks. All these factors will help a Product Owner to better prioritise Product Backlog as a list of everything that a team should do, including User stories, technical work, refactoring, defects, knowledge acquisition, spikes…
Agile teams strive to develop a software which is both high-quality and high in value, and the easiest way to develop a high-value software is to begin with implementing requirements of the highest priority. However, teams need to embrace changes, due to the fact that it’s inevitable that they will happen. The 2nd Agile Principle is about that, and one of the values from the Agile Manifesto says “Responding to change over following a plan”.
Agile approach recognizes a scope change as a common or more likely standard aspect in software development. Agile approach empowers developers to accept the scope changes as a way to produce software with a high value. Scope changes may appear at any time during the development. However, they are handled through incremental planning (roughly planning) and sprint planning (detailed planning). Changes should not happen during a Sprint. Any scope changes may be clarified/re-negotiated between the PO and the Dev Team as more is learned that way. A development team has to make a decision about how feasible it is to apply particular change during the current Sprint, considering current status of the Backlog and its capacity.
If you want to find out more about Requirement Prioritization, and other Agile Practices and Techniques regarding customer’s requirements management, consider the possibility of attending one of the Advanced Agile Trainings. And if you find yourself in a role of someone responsible for Product Backlog and its management and prioritization, you should definitely attend the Certified Scrum Product Owner course. The next one is scheduled for Agile Month – November 2016. Register on time!
