Agile Extension to the BABOK Guide

The Agile Extension to the BABOK® Guide is the draft that the International Institute of Business Analysis and the Agile Alliance published in November of 2011 for public review.

• Acceptance Criteria. Requirements that must be met in order for a solution to be considered acceptable to key stakeholders.
• Acceptance Test Driven Development (ATDD). ATDD is a TDD instance that involves writing one or more tests (or "customer tests") for a customer‐centric feature, before the solution has been developed.
• Acceptance Testing. See User Acceptance Test.
• Agile. Agile refers to a group of principles and practices that promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self‐organization and accountability, a set of engineering practices intended to allow for rapid delivery of high‐quality software, and a business approach that aligns development with customer needs and company goals. Also see Agile Manifesto, Agile Software Development.
• Agile Manifesto. The Agile Manifesto is a statement of the principles that underpin Agile Software Development. It was drafted from February 11th through 13th, 2001.
• Agile Retrospective. Retrospectives are a variation of project retrospectives whereby the retrospective workshop is conducted at regular intervals throughout the delivery process, such as after each iteration and/or release.
• Agile Software Development. Agile software development refers to a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self‐organizing cross‐functional teams.
• Anti-pattern. A commonly used, yet ineffective, process or practice.
• Backlog. See Product Backlog.
• Backlog Item. An element that belongs to a product backlog. It can be a feature, a bug fix, a document, or any other kind of artifact.
• Behavior Driven Development (BDD). An approach that enhances the communication between business users and the development team by using real examples.
• Burndown Chart. Used to track the work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward. Also see Release Burndown Chart.
• Business Value. In management, business value is an informal term that includes all forms of value that determine the health and well‐being of the firm in the long‐run. In agile development, business value is related to all deliverables that increase/protect revenue or reduce/avoid costs in a business.
• Ceremonies. Controlled processes and documents that constitute events and outputs in any given methodology. A high degree of ceremony frequently implies a high degree of control and traceability. Based on the just‐in‐time and just‐enough model, agile projects generally have a lower degree of ceremony. Agile ceremonies include iteration planning, daily meetings, and retrospectives.
• Change Driven Methodology. A software development approach that refers to a group of principles and practices that promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self‐organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high‐quality software, and a business approach that aligns development with customer needs and company goals.
• Class-Responsibility-Collaboration (CRC) Cards. A brainstorming tool used in the design of object‐oriented software.
• Daily Burndown. See Burndown Chart.
• Daily Meeting. On each day of a sprint, the team holds daily meetings. Ideally they are held in the morning as they help set the context for the coming day's work. The daily scrum is not used as a problem‐solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub‐group immediately after the daily scrum.
• Daily Scrum Meeting. See Daily Meeting.
• Daily Standup. See Daily Meeting.
• Elicitation. An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (for example, interviews, prototypes, facilitated workshops, documentation studies) to gather requirements from those sources.
• Enterprise Analysis. Describes how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. This knowledge area describes problem definition and analysis, business case development, feasibility studies, and the definition of solution scope.
• Epic. A piece of functionality that enables a user to achieve a clearly identified business objective. Often Epics are at the level of Elementary Business Processes‐‐‐a piece of work undertaken by one person, at one time, in one place that delivers on a specific operational objective.
• Feature Injection. An analysis technique based on real options and Kolb's model of learning. It can be used to efficiently identify the business value, and then determine the minimum set of features necessary to deliver that value.
• Iteration Burndown. See Product Burndown Chart.
• Just-in-time Requirements. Requirements that define only what is needed for the current iteration and only to the level of detail required for the team to deliver the item.
• Lean Development. An agile methodology that is guided by 7 principles: eliminate waste, amplify learning, decide as fast as possible, empower the team, build integrity in, and see the whole.
• Minimal Marketable Feature (MMF). A chunk of functionality that delivers a subset of the customer's requirements, and that is capable of returning value to the customer when released as an independent entity.
• Minimal Viable Feature (MVF). Commonly used with new products. Also see Minimal Marketable Feature.
• On-site Customers. The term used for the individual responsible for the relative priorities for the solution requirements in the Extreme Programming methodology.
• Operations Reviews. A time‐based process that is used to evaluate milestones and ensure the production environment is monitored and measured.
• Pair Programming. A development technique, frequently used in Extreme Programming, where two programmers work together one computer, developing code. Generally one programmer writes the code while the other reviews the code.
• Persona. Fictional characters or archetypes that exemplify the way that typical users will interact with a product.
• Plan-driven. A software development approach that follows an orderly series of sequential stages. Requirements are agreed upon, design is created and then the code is developed, and tested.
• Planning Game. The process used in Extreme Programming to conduct release planning and iteration planning. Both types of planning is broken down into three distinct phases: exploration phase, commitment phase, and steering phase.
• Planning Poker. At technique used in relative estimation that uses the entire team to contribute to the estimated work effort. During this group exercise, each member of the team has a set of cards that have story point values on them. The stories are presented and then each team member submits the card that has the value of story points that they feel is how much effort is required to deliver the story. The process is repeated until consensus is reached for each story.
• Potentially Shippable Product Increment. Scrum requires that each sprint deliver a potentially shippable product increment. The increment must consist of thoroughly tested code that has been built into an executable, and the user operation of the functionality is documented either in Help files or user documentation.
• Product Backlog Item. In Scrum, a product backlog item (PBI, backlog item, or item) is a unit of work small enough to be completed by a team in one sprint. Backlog items are decomposed into one or more tasks.
• Product Burndown Chart. In Scrum, the product burndown chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a release burndown chart is limited to a single release. Also see burndown chart.
• Product Champion. See Product Owner.
• Product Owner. The product owner represents the interests of all stakeholders, defines the features of the product and prioritizes the product backlog.
• Product Roadmap. An initial high level project scope and direction. It may include an initial architecture.
• Rapid Application Development (RAD). A generic term referring to any number of lighter‐weight approaches, using fourth‐generation languages and frameworks (such as web application frameworks), which accelerate the availability of working software.
• Rational Unified Process (RUP). An iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.
• Relative Estimation. A way of estimating work effort by identifying features/requirements with stories and then assigning story points to each story. The cumulative story points are the amount of effort to estimate the amount of effort required to deliver each story. The story points are then calculated against the team's velocity to create an estimate on how much the team can deliver in a particular iteration.
• Release. The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.
• Release Burndown Chart. The release burndown chart is a "big picture" view of a release's progress. It shows how much work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is a single release; however, a product burndown chart spans all releases. Also see Product Burndown Chart.
• Release Planning. At the beginning of a project the team will create a high‐level release plan. The team cannot possibly know everything up front so a detailed plan is not necessary. The release plan should address: the number and duration of the iterations, how many people or teams should be on this project, the number of releases, the value delivered in each release, the ship date for the releases.
• Scrum Master. The Scrum Master is responsible for making sure a Scrum team lives by the values and practices of Scrum. The Scrum Master protects the team by making sure they do not overcommit themselves to what they can achieve during a sprint.
• Scrum Team. The Scrum Team builds the product that the customer is going to consume: the software or website, for example. The team in Scrum is "cross‐functional" ‐ it includes all the expertise necessary to deliver the potentially shippable product each sprint ‐ and it is "self‐organizing", with a very high degree of autonomy and accountability.
• Shippable Product. A fully tested unit of code which meets acceptance criteria, that is delivered at the end of an iteration.
• Service Level Agreements. Formal agreements that contract level of service and performance.
• Solution Assessment and Validation. The set of tasks that are performed in order to ensure that solutions meet the business need and to facilitate their successful implementation. These activities may be performed to assess and validate business processes, organizational structures, outsourcing agreements, software applications, and any other component of the solution.
• Spike. An experiment to explore potential solutions or build a partial solution. Spikes are created to figure out answers to tough technical or design problems.
• Sprint. An iteration of work during which an increment of product functionality is implemented.
• Sprint Backlog. Items selected from the product backlog to be delivered in the current sprint, and their tasks.
• Sprint Goal. The Sprint Goal sprint goal is a short description of what the sprint will attempt to achieve.
• Sprint Planning Meeting. The Sprint Planning Meeting is attended by the product owner, scrum master, the entire scrum team, and any interested and appropriate management or customer representatives. During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog.
• Sprint Retrospective. The Sprint Retrospective is the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results.
• Sprint Review Meeting. A meeting where the scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features. Participants in the sprint review typically include the product owner, the scrum team, the scrum master, management, customers, and engineers from other projects. During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it is more important that they achieve the overall goal of the sprint.
• Standup Meeting. See Daily Meeting.
• Story. See User Story.
• Story Mapping. A Story Map is a tool to assist in creating understanding of product functionality, the flow of usage, and to assist with prioritizing product delivery (such as release planning).
• Task Board. The task board shows all the work the team is doing during an iteration. It is updated continuously throughout the iteration – if someone thinks of a new task they write a new card and puts it on the board. Either during or before the daily meeting, estimates are changed (up or down) and cards are moved around the board.
• Team Velocity. The rate at which a team can consistently deliver software features per iteration. Typically, it can be estimated by viewing previous sprints, assuming the team composition. and sprint duration are kept constant. It can also be established on a sprint‐by‐sprint basis, using commitment‐based planning.
• Theory of Constraints. Developed by Dr. Eli Goldratt, the Theory of Constraints (TOC) holds that every system has at least one constraint limiting it. TOC's goal is to increase efficiencies by identifying and mitigating these constraints.
• UML. Unified Modeling Language (UML) is a standardized language used to visually articulate elements of a piece of software.
• User Acceptance Criteria. Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.
• User Story. A high‐level, informal, short description of a solution capability that provides value to a stakeholder. A user story is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.
• User Story Mapping. A workflow of a business process that breaks down tasks for each process and represents these tasks based on priority.
• Value driven development. A process used to prioritize requirements or backlog items based on business value.
• Velocity. See Team Velocity.
• Waterfall. A software development approach that follows an orderly series of sequential stages. Requirements are agreed upon, design is created and then the code is developed, and tested.
• Whole Team Testing. The concept embraced by may agile methodologies where the entire project team is responsible for quality assurance and testing the code.