The discussion of scope among stakeholders should also occur during the requirements gathering process. There’s a big pressure to fit in as much as possible into a sprint, but it’s important to stop and think about what amount of work is realistic to include. Business priorities need to be weighed against the resource limitations (number of people available to do the work and time available) in order for testing to deliver maximum value. Some considerations for scope include: - Specific features or key transactions to be tested - Types of tests included (component test vs end-to-end test) - Test scenarios (peak load test vs disaster recovery) - Applications included in testing It’s also a good idea to add things that will not be tested. As with most things in the planning phase, scope is something that can change during the test when unexpected circumstances arise or when priorities change. But it's still a good practice to define the scope at the beginning, and update it as it changes. ## Scope in [[Shape Up]] methodology Projects in [[Shape Up]] are called "shaped work", and one of the basic properties of shaped work is that it is bounded. > shaped work [also] indicates what __not__ to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out. [^01] The process of bounding the work is called [[Shaping work (Shape Up)|shaping]]. ## References [^01]: [Basecamp's Shape Up](https://basecamp.com/shapeup/webbook)