Glossary Flashcards

1
Q

80:20 rule

What is another name for the 80:20 rule?

A

80% of consequences stem from 20% of causes; focus on the 20% that matters.

Pareto Principle.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the Agile Manifesto?

A

Defines the Agile approach, created 2001

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Benefits Assessment

A

A PRODUCT: describes how the benefits have actually accrued after a period of use in live operation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Business Case

A

A PRODUCT: baselined at the end of Foundations to provide vision and justification for the product from a business perspective

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Bottom Up

A

ESTIMATING TECHNIQUE: components are estimated individually and then added together

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Burn Down Chart

A

A chart counting the no. of features remaining [work remaining] or time left to complete [time remaining] for the current increment or timebox.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Team members subtract time from Burn Down Charts. True or false?

A

False - they always re-estimate time remaining.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Re Burn Down Charts:

Time remaining is used at which level?

Work remaining is used at which level?

A

Time = timebox level

Work = increment level

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What are Burn Down Charts used to predict?

A

When the work will be completed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Burn Up Chart

A

A chart showing features/requirements completed and the value earned so far.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Team Board / Big Visible Chart (BVC) / Information Radiator / Kanban Board

A

A graphical representation of project/timebox information in a public place (transparency). Can be hand drawn or digital.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Delivery Plan

A

A PRODUCT: provides high-level schedule of Increments for the project and the timeboxes that make up the first/imminent increment.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Development Approach Definition (DAD)

A

A PRODUCT: baselined at the end of Foundations, it define the tools, techniques, practices and standards that will be applied in Evol. Dev.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Development timebox (or just ‘timebox’)

A

A period of time in Evol. Dev. where solution development and testing takes place.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Evolving Solution

What does this include? (5)

A

A PRODUCT: made up of all components of the ultimate solution together with any intermediate deliverables. These components may either be complete or a work in progress, depending on the time.

Models, prototypes, supporting materials, testing and review materials

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Feasibility Assessment

A

A PRODUCT: a snapshot of the evolving business solution and management products as they exist at the end of Feasibility.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Foundations Summary

A

A PRODUCT: a snapshot of the evolving business solution and management products as they exist at the end of Foundations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Function / feature / requirement / User Story

A

Something the ultimate solution needs to have or be able to do.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Increment Timebox

A

Timebox at the Increment (life cycle) level. Calculated by adding together that Development Timeboxes for the Increment.

20
Q

MoSCoW

A

A prioritisation technique, mainly used on requirements.

21
Q

Management Approach Definition (MAD)

A

A PRODUCT: baselined at the end of Foundations, it reflects the approach to management for the project, i.e. how it will be organised and planned, how stakeholders will be engaged, how progress will be demonstrated and reported.

22
Q

Management by Exception

A

A management approach where the SDT are empowered to evolve the detail of the solution. If they get stuck, they refer to the project-level roles.

23
Q

Minimum Usable Subset (MUST)

A

The minimum set of requirements needed to deliver a viable solution.

24
Q

Planning Poker

A

ESTIMATING TECHNIQUE: consensus-based using numbered cards. Used to estimate effort or relative size of user stories.

25
Q

Post-project

A

Lifecycle phase used to assess the business value delivered by the project.

26
Q

Pre-project

A

Lifecycle phase where the initial imperative is formalised in order to initiate a project.

27
Q

Prioritised Requirements List (PRL)

A

A PRODUCT: baselined at the end of Foundations, it describes the requirements the project needs to address and indicates their priority relatives to the project’s objectives and the business need.

28
Q

Project Approach Questionnaire (PAQ)

A

A questionnaire based on the instrumental success factors (ISFs) which helps flags potential risks for a DSDM project.

29
Q

Project Governance Authority

A

A panel of corporate decisionmakers who decide whether a project should proceed or not.

30
Q

Project Review Report

A

A PRODUCT: updated at the end of each Increment (lifecycle phase), it captures feedback re what has been delivered and what has not, learning points and business value that should now accrue.

31
Q

Project timebox

A

Timebox at the project level, comprised of the sum of the Increment Timeboxes

32
Q

RACI

A

A responsibility assignment matrix, describing participation by roles.

R = Responsible
A = accountable
C = Consulted
I = Informed
33
Q

Release

A

A collection of features being deployed into operational use. May comprise one or more Increments (i.e. timeboxes’ worth of work)

34
Q

Solution Architecture Definition (SAD)

A

A PRODUCT: baselined at the end of Foundations, it provides the design framework for the solution.

35
Q

Scope

A

A description of what the solution will do and what it will not an/or which business areas will be included, i.e. the breadth.

36
Q

Servant-Leader

A

A leader that shares power, puts the needs of others first and helps people develop and perform as highly as possible.

37
Q

Story Points

A

A unit of size used for estimating, planning or tracking an Agile project.

38
Q

Test Driven Development (TDD)

A

An approach whereby the test is developed BEFORE the solution. The solution is built to pass the tests.

39
Q

Terms of Reference (ToR)

A

A PRODUCT: high-level definition of the over-arching business drivers for, and top-level objectives of, the project.

40
Q

Timebox plan

A

A PRODUCT: created for each Development Timebox, elaborating on the objectives, deliverables, the activities to be done and the resources needed. Created by the SDT and displayed on the team board.

41
Q

Timebox Review Record

A

A PRODUCT: created for each Development Timebox, capturing feedback from review. Describes what has been achieved and points for moving forward.

42
Q

Top-Down

A

ESTIMATING TECHNIQUE: uses approximate sizings and groupings, e.g. 10 components take 2 days. Groupings are then summed to give an estimate for the solution.

Used when low-level detail is still unknown.

43
Q

Total Cost of Ownership (TCO)

A

The cost of the whole life of a project/solution, not just development costs, e.g. maintenance, repair etc.

44
Q

User Story

What is the format?

A

A requirement expressed from the point of a user and with associated acceptance criteria.

As a I need so that .

45
Q

Velocity

A

The rate at which the team delivers business value. Initially estimated but then validated by the team’s track record. Used for planning.

46
Q

What are Functional Requirements (FRs)?

A

Those that define a function or feature, i.e. WHAT is required.

47
Q

What are Non-Functional Requirements (NFRs)?

A

Those that describe solution attributes/behaviour, i.e. HOW it will be achieved.

Attributes also known as ‘-ilities’, e.g. reliability