|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:
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 Estimation||Using this approach, each component is estimated individually and then the estimates estimating are summed to find the total effort. So you estimate the time to create the full product by starting with all the components. This gives a much better estimate but it can take forever.|
|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 AgilePM 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 AgilePM phase which focuses on getting the solution or part of it into operational use.|
|Engineering||The AgilePM 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.|
|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.
|MoSCoW||An DSDM prioritisation technique, mainly used on requirements although also useful in other areas (such as Testing).
|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” and “Should haves” using the MoSCoW technique.
|Pizza||A colloquialism for either the Exploration phase or the Engineering phase which are shown as round circles on the AgilePM lifecycle diagram.|
|Post-Project||The AgilePM phase which takes place after the last planned Deployment. It is used to assess the business value delivered by the project.|
|Pre-Project||The AgilePM phase where the initial idea or imperative is formalized in order to initiate a project. There can be an ambit of idea but only of few of these will be allowed to become a project.|
|Principle||A 'natural law' which acts as an attitude to take and a mindset to adopt on a AgilePM project. Principles are guides for good practice.|
|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 requirement and Feature. Requirements are gather by the Business Analysts and they come from the user community.|
|Retrospective (review)||A facilitated workshop to look back on a recent event and to assess what went well and what could be improved. This is a like a lesson review workshop.|
|ROI||Return on Investment. This can be calculated by the number of years for the project to recover the cost of the investment. Or it can also be expressed the financial benefits over 3 to 6 and 9 years.|
|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> e.g. As a user, I need to request on Forgot Password, so I receive an email and reset a new password for the system.
|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.
Keywords: AgilePM, AgilePM Foundation, AgilePM Practitioner, AgilePM Certification, AgilePM Exams, AgilePM PDF, AgilePM Manual