| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |

Reports an observed difference between expectation and fact.

Role responsible for executing acceptance tests and supporting Subject Matter Experts with their user acceptance tests.

A generalized notion of a unit of work with a clear purpose, spanning a few hours to a few days, usually executed by one Role and affecting one or a few Work Products.

Role responsible for obtaining clear requirements and for modeling Use Cases, by which he determines and guards functionality and scope of the system. He is also responsible for the overall screen flow and detailing the Use Cases.

Zie Taak.

Aims at validating a part of the proposed architecture in executable code. This takes place under the guidance of a small set of measurable acceptance criteria. Since an Architectural Proof of Concept is an experiment, it is good practice to rebuild the code for the deliverable software.

A set of well-designed and controlled, architecturally relevant code which is made available as example code for the Developer.

Role responsible for the applicable architectural rules with regard to infrastructure, information and application landscape as well as the reference architecture which the software has to comply to.

Workflow which shows how to ascertain that the solution’s spine is okay.

Shows the most important objects used in the business, the relations between these objects and the business rules that apply to them.

Phase in a RUP Lifecycle in which the solution is further developed toward a marketable feature set.

Represents activities that are repeated on a daily basis.

Describes the modeling of persistent data, commonly in a (relational) database.

A list that specifies when a piece of software is considered to be done. This list is an expression of and will ensure a common understanding of the desired quality constraints.
Session in which the team shows the Usable Increment made in the Sprint to management and stakeholders.
The Design Model describes the modeling of the most important software components. By bringing together data and functionality in objects and components (Object Oriented Design) this model is the basis for finding reusable functionality in the application.
Role responsible for the visualization of Use Cases and the technical design, development, documentation and (automation of) testing of software.
| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Phase in a RUP Lifecycle in which major design and implementation aspects of the solution are proven and agreed upon.
A consensus-based approach with team and stakeholders for estimating the relative size of a story early in a project.
Workflow which shows how to make final preparations for deployment.

The ratio between the total ideal man-hours estimated at the start of a Sprint and the regular man-hours available in that Sprint (focus factor = (estimated ideal man-hours / available regular man-hours) * 100%).

List of all terminology used in the project.
| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
A unit expressing how much time is needed to finish a task, assuming no interruptions and no major setbacks.
This list shows known impediments, which seriously hinder or block progress of the team and which need to be removed as soon as possible
Phase in a RUP Lifecycle in which objectives and a strategy for reaching them are agreed upon.
The time during which an application is developed toward a release. Also called Release Lifecycle.
| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Describes the overall navigation (navigation possibilities) of the application and establishes Use Case transcending rules about the User Interface.
Workflow which shows how to reach agreement on objectives and strategy.
A consensus-based approach for estimating the relative effort needed to implement a story using a set of planning poker cards.
Establishes a measurable basis for the work products that will be accepted. It contains a list of measurable acceptance criteria which fill in non-functional requirements as well as functional requirements which transcend the scope of individual Use Cases.
A prioritized list of functional and non-functional items.
Role which represents all Stakeholders toward the team. He prioritizes the functionality during the project by means of the Product Backlog, decides when Usable Increments go live, checks the coherence of the Usable Increments and accepts the incrementally evolving solution.

The Project Board is meant to guide the project in a balanced way. The most important stakeholders are represented in it in three roles:
• Executive (Sponsor)
• Senior User
• Senior Supplier

The Project Owner is responsible that the project meets the needs of the organization, that the project is funded and delivers the value to the demand organization.
The Senior User represents all stakes not being the Executive’s or Senior Supplier’s. This comprises, for example, end users, system administration and enterprise architecture stakes.
The Senior Supplier represents supplier organization’s stakes in the board.

| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Status of a user story indicating that the team is ready to estimate that story from the Product Backlog in such detail that they can accurately forecast if its implementation will fit in the upcoming Sprint.
A graphical presentation of the amount of work remaining until the planned release dates.
See Lifecycle
Every Usable Increment contains Release Notes listing all delivered physical parts (code and documents), realized Use Cases and, if applicable, known issues and bug fixes.
Session in which the team looks back to the Sprint for improvement opportunities in the next Sprint.
Lists the known project risks.
A Role defines a set of related skills, competencies, and responsibilities. In a Workflow it is responsible for the Activities beneath it. A Role is not owned but played by a person. Any team member picks his Roles as needed.
A measure to find the amount of user – system interaction. One round trip starts with a stimulus from the user, which the system processes and returns to the user.
Role that facilitates the Team and in that way ensures that the Team adheres to the Scrum values and practices. He helps the Team to understand and use self-organization.
Consists of the Self-organizing Team plus the Scrum Master and Product Owner.
Role responsible for making, explaining and documenting technical choices in the project which determine the software architecture and therefore the technical borders and possibilities of the system. He is also responsible for communicating the architecture and supervises its implementation.
Gives a survey of the architecture of the system, in which various views (among others: Use Case, Logical, Implementation, Deployment view) clarify various aspects of the system.
A (possibly composite) document which contains all information to manage the project. It is assembled and baselined in Inception and updated during the lifecycle(s).
See Sprint cycle
Shows the tasks the team has planned to be performed in this Sprint. The tasks relate to Use Case Scenarios or any other items to which the team has committed this Sprint.
Shows how much work there is left to do until the end of the Sprint.
Represents a time box or iteration in which a Usable Increment of the solution is developed.
Meeting in which the Product Owner and the Self-organizing Team sit together to select stories to implement in the upcoming Sprint from the top of the Product Backlog.
Meeting dedicated to review the Sprint Result: updating the Product Backlog with insights from the last Sprint (remove stories that are done, re-estimate stories that are partially done or better known now). This meeting includes a demo by the team of the Increment they implemented in the past sprint.
Workflow which shows how to work together in a Sprint.
A daily 15 minute team meeting at the Task Board to discuss progress. This meeting is meant to minimize the need for other team meetings. Every team member tells what he has done and learned yesterday and what he is going to contribute to the team effort today. Any impediments holding him back that he needs help with are shared.
An umbrella term for items on the Product Backlog (items include Epics, Use Cases and Use Case scenarios).
A means of visualization of different granularities of requirements (typically epics, use cases and scenarios), their relations and the relation to the business processes.
This role is filled by an experienced user of specific Use Cases or by a person who is an expert with respect to (part of) the business domain. He has a central function in determining the functionality needed. Subject Matter Expert and Analyst will closely cooperate in shaping the Use Cases. This role will also participate in user acceptance tests.
This documentation contains three views:
• The configuration view, with application specific installation, configuration and maintenance directions.
• The installation view, with a roadmap for deploying the application. It is an explanation of the approach to be followed in order to have the software installed in test, acceptance and production environment and the way in which the software is to be moved forward from environment to environment.
• The maintenance view, in which a roadmap is given for regular application maintenance.
This role contains various specializations: System administration (in the strict sense), middleware administration and application administration (technical and functional). In many projects all these specializations are needed.
A task on a task board is a unit of work, usualy of one day or less. It result from the team planning how to deliver a Story from the Product Backlog into “Done” product.
The Team consists of IT-specialists and Subject Mater Experts. The Team forecasts the amount of work it can handle in a Sprint. In the Team, several roles are present: Subject Matter Expert, Analyst, Software Architect, Developer, Tester and Tool Administrator.
Summarizes test activities and test results per Sprint.
A coherent set of test aids. It encompasses preferably automated test cases (developer tests and other tests) and an environment to run them. It also includes any test data, scripts, tools and other aids for executing and maintaining tests.
Role responsible for specifying Test Cases and performs the execution of the Test Cases.
Role responsible for setup and administration of tools which constitute the development and test environment.
Phase in a RUP Lifecycle in which the solution and organization are finalized for release to production.
A collection of software and supporting work products which can be handled by the demand organization.
A comprehensive survey of identified Actors and Use Cases, their relation, weight and classification. Each Use Case is described accurately but concisely. The relations between Use Cases are shown in the Use Case diagram.
Estimation unit applicable to Use Cases or User Stories. 5 points amounts to a small story, 10 to a medium and 15 to a large one. Use Case Points are quite handy for an early estimation in hours.
Selection of one or more (parts of) scenario’s from a Use Case to form a suitably sized work item to fit in a Sprint that is of clear value to the customer. It slices the requirements, design, implementation, test assets and documentation.
The detailed description of the interaction of Actor (human or machine) with the system. This description shows a valuable result to the Stakeholder or user. The interaction steps can be performed coherently and uninterrupted.
All documents, posters, presentations, workshops, assignments, exams, online training and the like, needed to train end users in using the application.
| A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Describes the common perspective of demand and supply organization with regard to the project. It establishes features and borders of the system, its Stakeholders and the context in which the demand organization will use the system.
Meeting in which the team details the work that will have to be done to implement the stories for the Sprint.
A generalized notion of anything used, produced, or modified in the process. A Work Product can be a piece of code, a document, a model, etcetera.
A Workflow defines a breakdown as well as a flow of work. It is a semi-sequential, high level representation of (part of) a process. It shows Roles executing tasks to produce Work Products.
Source code including code documentation, frameworks, database implementation and configuration settings which together deliver a meaningful chunk of functionality to the business.