During
Propose iterations, the scope of the project is first outlined (using smart use cases) to be able to estimate to total size in complexity of the project, so that a project proposal can be delivered. Next the customer decides to go through with the project, or to stop (at minimal cost). If the customer decided to continue, there's two options:
- Scope the project. The project continuous by only executing one or more Scope branded iterations. This option can be useful, if the project is complex and requires some further investigation. This might be the case for instance in a service-oriented project, where it important to identify services, and to establish whether these service are already present, need to be parameterized or built.
- Run the project. The customer might also decide to execute the full project. In this option running one or more Scope typed iterations is still recommendable, for the same reasons.
Scope typed iterations set out to establish, but also delimit the scope for the project, and to re-value the project estimate from the
Propose, based on looking at possible re-use. The end product of
Scope is a pragmatic project plan (need not contain dozens of pages), that groups all products previously delivered that are delivered during both the
Propose and
Scope stages. Think of the project estimate, identified re-use, the smart use case estimate and diagrams (as appendices).
Read more
- Smart iteration cycle. Each iteration in a Smart project follows the same pragmatic iteration cycle to deliver products.
Goals
Scope iterations target at:
- Establish scope. Establish the full scope of the project, including smart use cases, the buseinss domain, reusable services and a first-cut software architecture.
- Delimit scope. Many projects are time-limited and will need to deliver to a predefined deadline, for instance because a marketing campaign starts, and the website to register new customers needs to be deployed when the campaign starts. It is therefore a worthwhile exersice to try to delimit the scope of the project by ruling out everything that does not directly add value to the business case. In most projects not all smart use cases that were identified will make the end product.
- Have project plan. Write the project plan for the project, that includes the process used, the people involved, the business case and the product delivered during the Propose and Scope iterations.
End product
The end product for a (sequence of)
Scope iteration(s) is the project plan. This plan is required by the customer to decide on the continuation of the remainder of the project's iterations, based on the adjusted estimate.
Suggested products
We suggest to add the following products to the project backlog when starting (a)
Scope iteration(s):
- Glossary. A glossary shortcuts a common vocabulary for the project, expressed in customer lingo, and preferably placed in a public available location, such as a project wiki.
- Domain model. Define your first-cut domain model, containing the most important domain objects, value objects and other domain driven elements. The primary goal of this exercise is to get a first idea on the domain. This will help identifying the software architects and the possible reusables. Do not extend this model to full detail here.
- User interface style. Define the guidelines for developing the user interface. Sometimes these will consist of wire frames, sometimes you will have to write style sheets. In many organizations however, these guidelines are already available, in most cases from the communications department.
- Additional requirements. In a Smart project, functional requirements are modeled in smart use case diagrams. It is good practice to gather a list of non-functional requirements, including any supplementary specifications - meaning any associated loose requirements that are not directly related to either a smart use case or a non-functional requirement.
- Software architecture. Investigate the required software architecture for your project. In the Accelerated Delivery Platform we've defined a number of reference architectures, that can serve as a starting point. but there's other alternatives as well. Applying a reference architecture save valuable time in that investigating the software architecture merely comes down to identifying the delta from your reference archtitecture. Where does our software architecture need to deviate?
- Development environment. As Scope iterations are also preparing the project to go over to Realize, it is also recommandable to set up your development environment, arrange continuous integration policies, possibly set up your test and acceptance environment, and to try to connect to any outside world services, such as databases, middleware or cloud based services. Your Scope iteration is a good moment to set up your environment, given that the project isn't halted at the end of the iteration.
- Reusables. List elements that can be (re)used to crank up your project, such as guidelines, documentation templates, exisiting components, (web) services, frameworks. This is the moment to see where your organization's services are located, whether they can be reused as is, or require tuning (parametrization according to SAP) to be used in your project. A simple technique that works quite well is to go through all smart use case diagrams, and find out if re-use is possible, not only for front end smart use cases, but even more so for identified services.
- Fine-tuned estimate. Adjust your original estimate to newly gained insights around software architecture, user interface and reusables.
- Project plan. Finally, write the project plan for the remainder of the project. This project plan include all the products delivered during Propose and Scope, but also defines the required resources, the timelines for the project, and its communication scheme.