Glossary
Term/Abriviation Description
A-D | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |

Acceptance Finding

Reports an observed difference between expectation and fact.
Acceptance Tester

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

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.

Analyst

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.
Activiteit

Zie Taak.

Architectural Proof of Concept

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.

Architectural Prototype

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

Architecture Owner

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.

Architecture Workflow

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

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

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

Daily cycle

Represents activities that are repeated on a daily basis.

Data Model

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

Definition of Done

 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.
Demo Session in which the team shows the Usable Increment made in the Sprint to management and stakeholders.
Design Model 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.
Developer Role responsible for the visualization of Use Cases and the technical design, development, documentation and (automation of) testing of software.
E-H | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Elaboration Phase in a RUP Lifecycle in which major design and implementation aspects of the solution are proven and agreed upon.
Estimation Game A consensus-based approach with team and stakeholders for estimating the relative size of a story early in a project.
Finalization Workflow Workflow which shows how to make final preparations for deployment.

Focus Factor

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%).
Glossary List of all terminology used in the project.
I-L | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Ideal Man-hour A unit expressing how much time is needed to finish a task, assuming no interruptions and no major setbacks.
Impediments List This list shows known impediments, which seriously hinder or block progress of the team and which need to be removed as soon as possible
Inception Phase in a RUP Lifecycle in which objectives and a strategy for reaching them are agreed upon.
Lifecycle (development) The time during which an application is developed toward a release. Also called Release Lifecycle.
M-P | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Navigation Map Describes the overall navigation (navigation possibilities) of the application and establishes Use Case transcending rules about the User Interface.
Objectives Workflow Workflow which shows how to reach agreement on objectives and strategy.
Planning Poker A consensus-based approach for estimating the relative effort needed to implement a story using a set of planning poker cards.
Product Acceptance Plan 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.
Product Backlog A prioritized list of functional and non-functional items.
Product Owner 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.
Project Board

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.
Q-U | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Ready to Poker 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.
Release Burnup Chart A graphical presentation of the amount of work remaining until the planned release dates.
Release lifecycle See Lifecycle
Release Notes 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.
Retrospective Session in which the team looks back to the Sprint for improvement opportunities in the next Sprint.
Risk List Lists the known project risks.
Role 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.
Round trip 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.
Scrum Master 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.
Scrum Team Consists of the Self-organizing Team plus the Scrum Master and Product Owner.
Software Architect 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.
Software Architecture Document 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.
Software Development Plan 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).
Sprint See Sprint cycle
Sprint Backlog 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.
Sprint Burndown Chart Shows how much work there is left to do until the end of the Sprint.
Sprint cycle Represents a time box or iteration in which a Usable Increment of the solution is developed.
Sprint Planning Meeting 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.
Sprint Review Meeting 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.
Sprint Workflow Workflow which shows how to work together in a Sprint.
Stand-up Meeting 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.
Story An umbrella term for items on the Product Backlog (items include Epics, Use Cases and Use Case scenarios).
Story Map A means of visualization of different granularities of requirements (typically epics, use cases and scenarios), their relations and the relation to the business processes.
Subject Matter Expert 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.
System Administration Documentation 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.
System Administrator 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.
Task (on task board) 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.
Team (Self-organizing) 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.
Test Report Summarizes test activities and test results per Sprint.
Test Suite 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.
Tester Role responsible for specifying Test Cases and performs the execution of the Test Cases.
Tool Administrator Role responsible for setup and administration of tools which constitute the development and test environment.
Transition Phase in a RUP Lifecycle in which the solution and organization are finalized for release to production.
Usable Increment A collection of software and supporting work products which can be handled by the demand organization.
Use Case Model 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.
Use Case Point 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.
Use Case Slice 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.
Use Case Specification 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.
User Support Material All documents, posters, presentations, workshops, assignments, exams, online training and the like, needed to train end users in using the application.
V-Z | A-D | E-H | I-L | M-P | Q-U | V-Z | Top |
Vision 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.
Work Breakdown Meeting Meeting in which the team details the work that will have to be done to implement the stories for the Sprint.
Work Product 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.
Workflow 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.
Working Software Source code including code documentation, frameworks, database implementation and configuration settings which together deliver a meaningful chunk of functionality to the business.