Difference between revisions of "Glossary"

From AgilePM wiki
Jump to: navigation, search
Line 9: Line 9:
 
|-
 
|-
 
|BAD
 
|BAD
|The Business Area Definition. An element of the Solution Foundations product produced during the Foundations phase.
+
|The Business Area Definition. An element of the Solution Foundations product produced during the Foundations phase. BAD is also a song by Michael Jackson :-)
 
|-
 
|-
 
|Bottom Up
 
|Bottom Up

Revision as of 12:54, 14 December 2016

80:20 rule This is known as the Pareto Principle. It is a rule of thumb stating that 80% of consequences stem from 20% of causes. The value of the Pareto Principle is that it reminds you to focus on the 20% that matters. Some examples of using this is a sentence:
  • 80% of products sales are with 20% of our clients
  • 80% of complaints are linked to 20% of our products

It is the easier to see what should be focused on.

BAD The Business Area Definition. An element of the Solution Foundations product produced during the Foundations phase. BAD is also a song by Michael Jackson :-)
Bottom Up Using this approach, each component is estimated individually and then the estimates estimating are summed to find the total effort.
Burn-down chart A publicly displayed chart or graph counting the number of features/requirements remaining [work remaining] or time to complete the outstanding work [time remaining] for the current Increment or Timebox. Time to complete is always re-estimated, rather than simply subtracting time spent from the original estimate. Time remaining is more commonly used at Timebox Level. Work remaining is more commonly used at Increment level. Burn-down is useful for predicting when all of the work will be completed, based on the current rate of progress. [Velocity]. (This information can also be presented as a Burn-Up chart, showing work/time completed)
Burn-up chart A publicly displayed chart showing features/requirements that have been completed and the value earned so far.
Cheese A colloquialism for the Feasibility and Foundations phases which are represented on the DSDM lifecycle diagram as a cheese shape.
DAD The Development Approach Definition. An element of the Solution Foundations product produced during the Foundations phase.
Deployment The DSDM phase which focuses on getting the solution or part of it into operational use.
Engineering The DSDM phase used iteratively and incrementally to evolve the solution created during Exploration.
Exploration The DSDM phase which is used iteratively and incrementally to investigate the detailed requirements and translate them into a form which can then be evolved into a viable solution.
Feasibility The DSDM phase which gives the first opportunity for deciding whether or not the project is viable from a technical or business perspective.
Foundations The DSDM phase to establish firm and enduring foundations from the three perspectives on a project of business, solution and management.
Function/Feature See requirement.
Increment 1. A partial delivery of the final product, preferably into operational use if possible.

2. A part of the project which creates the partial delivery.

Iteration 1. A general term for working in a cyclic way, where several attempts are made in order to get a more accurate or beneficial result.

2. One cycle of Identify, Plan, Evolve and Review which takes place one or more times inside a Development Timebox.

Minimum Usable Subset (MUS) The minimum set of requirements that can be delivered to meet the business need.

This is defined as the Must Haves.

MoSCoW An DSDM prioritisation technique, mainly used on requirements although also useful in other areas (such as Testing). M stands for Must Have, S stands for Should Have, C stands for Could Have and W stands for Won't Have This Time.
Pizza A colloquialism for either the Exploration phase or the Engineering phase which are shown as round circles on the DSDM lifecycle diagram.
Post-Project The DSDM phase which takes place after the last planned Deployment. It is used to assess the business value delivered by the project.
Pre-Project The DSDM phase where the initial idea or imperative is formalised in order to initiate a project.
Principle A 'natural law' which acts as an attitude to take and a mindset to adopt on a DSDM project.
PRL Prioritised Requirements List - A document holding a list of requirements for the final solution which have been prioritised using the MOSCOW technique. It may also hold other information, such as estimates and actuals.
Prototype A piece of work that demonstrates how a given objective can be or has been achieved.
Requirement Something the final solution needs to be able to do or to do to a certain level of performance. Similar to the words Function and Feature.
Retrospective A facilitated workshop to look back on a recent event and to assess what went well and what could be improved.
ROI Return on Investment.
SAD The System Architecture Definition. An element of the Solution Foundations product produced during the Foundations phase.
Scope A description of what the solution will do and what it will not do. This could be a list of features and/or a description of areas of the business which may or may not be affected.
Story points A relative unit of size, used for estimating, planning and tracking in an Agile project.
TCO Total Cost of Ownership. The cost of the whole life of a project, including support (rather than just considering the development cost).
Timebox A fixed period of time, at the end of which an objective has been met. The objective would typically be a deliverable of some sort. Typically Timeboxes operative at development level, but timeboxing can also be applied at project and increment level. A -timebox is managed by adding or removing content in order to meet the timebox objective and the deadline.
Top-Down A technique for estimating using approximate sizings and groupings. For example, 10 estimating small components at typically one day each, 20 medium components at typically three days each, three complex components at typically five days each. These groups are summed to give an approximate estimate for a solution where the low level detail is probably still unknown.
User Story A requirement expressed from a user point of view. The usual format is:

As a <role> I need <the requirement or feature> so that <benefit to be gained>

Velocity Velocity is a simple measure of the rate at which a team delivers business value. Velocity (initially estimated but soon validated by the team's track record of delivery) is used for forward planning. E.g. In an Increment of 4 x 2 week Timeboxes, a team with a velocity of 25 points can confidently plan to deliver about 100 points. NB A velocity score is individual to a team (their velocity signature) and should not be used as a comparative measure across teams.