4.2: Scope Management in Agile vs. Waterfall - Video Tutorials & Practice Problems

<v ->Now, let us talk about scope management</v> and requirements management in Agile versus Waterfall. We will start with Waterfall, or traditional project management. Software requirement specification in Waterfall is a document that describes features and capabilities provided by the product and the performance requirements. It also describes the functionality that the products need to fill that the stakeholders, business customers, and user clients need. A software requirements documents usually contains functional requirements, customer centric, and nonfunctional. They're also defined as system based features, such as availability, reliability, or security. Software requirement specification structure is usually some variation of objectives, which have business objectives and how the product will be used in the context of its purpose by the customer, functional requirements, which are statement of functionality that can be viewed as contract with customers, nonfunctional requirements, performance, availability, usability, security, and so forth, and usually, there are some appendices that are used to capture any detailed information such as unified modeling language diagrams, list of user cases, data models, lists, wire frames, repositories, any other relevant details. Here on this slide, you see the requirement samples that are provided at ISO documentation that we referenced in the beginning of this class. However, requirements in Waterfall do not have to be captured the natural language. They're frequently captured and documented further as use cases or in a specific format, such as Universal Modeling Language, or UML. Use case methodology is an effective approach for documenting requirements that originated in object oriented programming. A use case is defined as a list of actions or steps that is needed to define the interactions between a role and the system to achieve a pre-defined objective. This could be human or could be an external system. The concept of use cases was introduced in 1987 by Ivar Jacobson, who described how this methodology was used to capture and specify requirements. This slide represents a simple use case scenario. As you can see, it's for an online bookstore and the following slide shows how this scenario is reflected from actor and system integration. This is called a use case diagram in Unified Modeling Language, or UML. software requirement specification serves as a foundation for a handshake between the customers and the software provider. Basically it tells us how the software product should function. The goal is to provide the relevant level of detail and the idea is to limit any every design or further changes to the list of required features. Usually it's very comprehensive, hundreds of pages, well defined document. It provides a clear and thorough understanding of the product that has to be built. So in traditional project delivery, the communication between the development team and the customer is limited. Usually it serves as an internal contract for the work that needs to be performed. And any changes to SRS are considered scope changes and that's not good, they require change management process, additional sign offs, it has impact on product delivery timelines, and this impact is estimated each time a change management request is processed. I mentioned that SRS usually contains hundreds of pages of documentation. It's accompanied by multiple appendices, they contain data models, description of business logic, data assumptions, wire frames, and all other relevant information. Usually the owner of SRS is a business analyst or technical writer or sometimes in small companies, a system architect or software developer. SRS users include managers, software engineers, test engineers, managers, and so forth. Frequently, business analysts start the work on software requirements from the business requirement document or BRD. It describes the high level business data. Then they proceed with the functional requirements document, or FRD. It outlines the functionality required to fulfill the business need. Based on all this information, then they proceed and create SRS, software requirements document. This document is the primary one and it contains technical information, documentation details, and serves as a primary input into development. Usually this document has to be fully finalized and signed before the development starts. In Agile, the approach is completely different. There is no single document. There is a list of discreet requirements organized in the order of their priority. It's called the product backlog. A product backlog is a living document. It continuously changes and gets updated on a regular basis. There is no change management process. The only exception is in Scrum. In Scrum, once the team makes the commitment for this specific sprint and starts the sprint, the scope of sprint is defined. Usually as we know, the sprint is two three or four weeks long so this definition is very short term and there is no change management process outside of the sprint. Within the sprint, any changes to scope have to be approved by the product owner. Once approved, those changes cannot be just added to the sprint because the team already has committed to this work based on their capacity. So if a product owner initiates a scoping conversation with the team, the team makes the decision. And usually the decision is to change, not add anything. So the team would take the new requirement and move one of the requirements out of the sprint. This allows the team to always maintain sustainable piece of their development.