Deliverables

The Agile UP distinguishes between:

Deliverable which you absolutely must produce as a permanent system work product.
Other project work products which you will likely discard because you do not want to maintain it over time.
Enterprise work products which are maintained within your IT department and shared across projects.

Fundamental advice for staying agile:

Keep your work products as simple and concise as possible.
You need a lot less documentation than you think.
Work closely with the people whom you're creating an work product for so that you produce only what they need.
Agile documents are just barely good enough for the task at hand.
Producing a document is the worst way to communicate information, several people standing around a whiteboard talking is the best.
Use simple tools such as plain old whiteboards (POWs), paper, and Wikis to model and capture documentation.
Consider adopting the open source templates as a basis from which to create your own. They're probably a lot more than what you want, but they're a good start.

Minimum Deliverables

The minimum deliverables for an Agile UP system are described, in priority order, in the following table:

Deliverable	Description	Tips	Templates
System	The working software, hardware, and documentation to be deployed into production.	There is more to your system than just the software that you write.
Source Code	The program code for your system.	Follow common coding guidelines.
Regression Test Suite	A collection of test cases, and the code to run them in the appropriate order. Your regression test suite will include a wide range of tests, including acceptance tests, unit tests, system tests, and so on.	Automate your tests. Run them as often as possible, ideally whenever anything changes.
Installation Scripts	Code for installing your system into your (pre-)production environment.	You will need a script, or scripts, to install into your pre-production environment as well as into production. You likely need de-installation scripts if your installation fails.
System Documentation	The documentation delivered as part of your system to help stakeholders work with it and developers to maintain and evolve it. Potentially comprised of operations, support, user, and system overview documentation.	Keep your documentation as lean as possible.
Release Notes	Your release notes should summarize the "good things to know" about the current release of the system which you're building.	Point form notes are often sufficient.
Requirements Model	Describes the requirements which your system should fulfill. Comprised of a variety of work products, potentially including acceptance tests, automation opportunities, business process model, business rules, domain model, organization model, project glossary, technical requirements, use case model, and a user interface model.	Your goal is to understand and then build what your stakeholders want, not to write mounds of documentation. You don't need to keep all aspects of your requirements model, just the portions that overview the scope of your system. Consider keeping: Business process diagram(s) which overview what your system. Your project glossary. Any requirements work products, such as point form use cases, that haven't been implemented yet. Acceptance tests for implemented requirements (they're part of your regression test suite).
Design Model	Describes the design of your system. Comprised of a variety of work products, potentially including a deployment model, an object model, a physical data model (PDM), a security threat model, a system overview document, and a user interface model.	Keep your design models as simple as possible, and discard as many as possible once you've achieved the value from them. The best place to document your design is in your unit tests and source code. Keep the system overview document and physical data model for permanent documentation. You may also want to keep a few critical detailed design diagrams, such as sequence diagrams or state machine diagrams.

Other Project Work Products

Other work products, listed in alphabetical order, which you may choose to create or use as a matter of course include:

Work Product	Description	Tips	Templates
Acceptance Tests	Acceptance tests describe black-box requirements, identified by your project stakeholders, which your system must conform to.	See Introduction to Acceptance Test Cases
AUP	The Agile Unified Process.
Automation Opportunities	An indication of manual activities which could potentially be automated.	This could easily be a simple, point form list.
Budget	An indication of the amount of funds, when you will receive the funds, and the criteria (if any) your team must meet to receive the funds, to support your project efforts.
Business Process Model	A description of the business activities, the information flows between them, and the sources/destinations of the information.	Data flow diagrams (DFDs), UML activity diagrams, and workflow diagrams are good options for visually describing the business process If you name the model elements well you likely will not need to write any supporting documentation.
Business Rules Specification	A business rule specification captures the collection of business rules implemented by a system. A business rule defines or constrains one aspect of your business that is intended to assert business structure or influence the behavior of your business. Business rules often focus on access control issues, business calculations, or policies of your organization.	Use a tool which describes business rules in human readable form and that generates working code from the business rule definition.
Data Schema	The schema of your data sources. In the case of relational databases, it's described by data definition language (DDL), for XML data sources you'll use XML schema definitions or XML DTDs.	Your data schema(s) should evolve in step with your application code.
Defect Report	A type of change request that defines a system-related problem; that is, the system is not working the way that it is supposed to.	Could be as simple as an email or entry in a spreadsheet. Consider using specific software for defect tracking during the Transition phase and once the system is deployed in production.
Deployment Model	Describes how you will organize the hardware, middleware, and software aspects of your system.	Keep it simple Often diagramed using a UML deployment diagram, a network diagram, or a free-form sketch.
Deployment Plan	Describes your approach to deploying your system into production.	Focus on dependencies with other groups. Identify your release window early in the project. Work closely with operations and support people. Should indicate training and education efforts. The technical details will be captured by your (de)installation scripts.
Domain Model	Depicts the main business entities, the relationships between them, and potentially their responsibilities.	Start by creating a slim domain model Should drive the development of your object model and data schema(s) Consider identifying responsibilities (data and behavior) instead of just data
Estimate	The projected cost for completing the project.	Present the estimate in a range. Update your estimate throughout the project. Agile estimating tips.
Individual's Estimate	An estimate made by an individual of the time and/or cost to perform a task.	The best person to do an estimate is the person responsible for it. Smaller things are easier to estimate.
Object Model	Describes your object schema, the code which comprises your software. Often comprised of several views for the static structure and the dynamic aspects of the schema.	For the static structure, consider UML class diagrams, UML component diagrams, and UML package diagrams. For the dynamic aspects, consider UML sequence diagrams, UML communication diagrams, and UML state machine diagrams.
Operations Documentation	Captures the procedures and supporting information to operate the system once it is in production.
Organization Assessment	Describes the organization (perhaps a division of your company) into which your system will be deployed, including an indication of the organization's ability to adopt and use the new system.
Organization Model	Indicates the people involved with your project and the reporting structure between them. Should indicate both the members of the project team as well as the major stakeholders and their roles.
Physical Data Model (PDM)	Describes the physical schema of a data store, such as a relational database or XML file.	Your domain model should drive the development of your PDM Evolve your PDM and object model in parallel Consider using UML notation
Project Glossary	Describes the critical business and technical terms on your project.	See the Introduction to Glossaries essay Reuse existing enterprise glossary definitions Consider using a Wiki for your glossary
Project Overview	Summarizes the goals, plan, and mission of the project. Potentially comprised of a project goals statement, project vision statement, and an organization assessment.	Should be concise. Point form lists are likely sufficient.
Project Plan	Comprised of iteration plans, the overall project schedule, risk list, estimate, and budget.
Project Resources	Comprised of funding, hardware/software, and facilities (such as rooms).
Project Schedule	Indicates the activities, the dependencies between them, and the project milestones.	A Gantt chart, or perhaps a Pert chart, is the most common approach to rendering a project schedule. See agile project scheduling tips. Schedule long-term activities at a high level, and near-term activities in more detail. People should plan their own work, and at most be assisted by the project manager.
Proof-of-Concept Prototype	Working code that shows that proves that a technical approach works.	During the Elaboration phase you must create a proof-of-concept prototype which shows your architecture works end-to-end.
Review Record	The results, including assigned action items, of a review.
Risk List	A list of identified risks, and mitigation strategies (if any).	Update your risk list throughout your project. Mitigate risks as soon as possible.
Security Threat Model	A model which explores security threats to your system.	See Introduction to Security Threat Models. Security threats are often depicted on UML deployment diagrams or on free-form architecture diagrams, so you might not have a separate diagram for this.
Support Documentation	The documentation required by your support staff, such as trouble shooting guides, contact information for the development team, which enables them to support end users.
System Overview Document	Technical documentation for the people responsible for maintaining and evolving the system.	Conciseness is critical Typically includes free form architecture diagrams, an overview of the business process(es) supported by the system, an indication of where the source code is stored, and a list of design decisions. If the original development team, or a portion of it, is responsible for maintaining the system then you'll need a lot less documentation than if you hand it off to another team.
Tailored Process	Comprised of the AUP, guidance, and templates tailored to the needs of the project team.
Technical Requirements	Describes non-behavioral issues such as usability, security, and performance. Often referred to as "non-functional" requirements.	See Introduction to Technical Requirements
Templates	An "electronic form" containing common information fields to fill out for a given kind of work product.	Keep them simple. Templates which contain every possible item you may ever want will motivate people to do far more documentation than they need to.
Test Model	Comprised of a Regression Test Suite and any Defect Reports.
Test Strategy	A description of your general approach to testing.	Reuse this from other projects.
Tools	The software packages used to develop your system.
Training Materials	The course notes, overview documentation, assignments, and so on used to help train end users, support staff, and operations staff to work with the system.
Use Case	Use cases describe something of value to a stakeholder and are a primary requirements work product of the Agile UP.	Point form use cases are often sufficient.
Use Case Model	A use case model is comprised of zero or more use case diagrams, use case descriptions, and actor descriptions.	The most important part of a use case model are the use case descriptions Point form use cases are often good enough Use case diagrams are often useful for management presentations, although process diagrams convey far more information
User Documentation	The manuals, help documentation, and so on that end users use to help them understand the system.	Remember to indicate how to contact support staff.
User Interface Model	Describes the user interface of your system.	Paper prototypes and whiteboard sketches of screens are good enough to get you to the point where you know what you need to build. User interface prototypes are useful during Inception and perhaps Elaboration, but during Construction you should write actual working code and not prototype code. UI navigation diagrams are useful to overview your user interface and explore usability issues.

Enterprise Work Products

Your enterprise teams (e.g. enterprise architects, database administrators, portfolio managers, ...) will often provide the follow work products to help guide and ease your project efforts:

Deliverable	Description	Tips	Templates
Enterprise Architecture Model	Depicts the frameworks, networks, deployment configurations, supporting technical infrastructure, and domain infrastructure for an organization.	Documentation is nice, but participation on project teams by enterprise architects is far more effective.
Enterprise Development Guidance	Standards and guidelines applicable to all systems within your organization, including coding guidelines, network guidelines, data standards, and so on.	Guidance should be concise, practical, and contain realistic examples.
Enterprise Guidance	Standards and guidelines to be followed within your organization, including development guidance, human resources guidance, modeling guidance, and usability guidance.
Enterprise Mission Statement	A statement of the strategies to be followed to achieve the enterprise vision.
Enterprise Vision	A statement of the primary goal(s) of an organization.	Should be a few, specific, points. Unfortunately this is rarely the case.
Human Resources Guidance	Standards and guidelines for people-management activities such as hiring, promoting, transferring, training, educating, and so on.
Modeling Guidance	Describes techniques such as naming conventions, layout style guidelines, and even notation style guidelines for how models should be organized and documented.	UML style guidelines exist.
Reference Architecture	An architectural approach designed and proven for use in a particular domain, together with supporting work products to enable their use; it often provides the basis for creating an application architecture.	Working software with a test suite and overview documentation is a very good way to package a reference architecture. Enterprise architects should help teams to understand and then apply the reference architecture.
Usability Guidance	Standards and guidelines for developing the user interface of a system and for determining its effective use.

Page last updated: May 13, 2006

This page is tailored with permission from Ambysoft Inc.'s Agile UP Product