Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
Agile Ext. Glossary
Terms from Agile Extension Guide
| Term | Definition |
|---|---|
| Acceptance Criteria | Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance |
| Acceptance Test Driven Development (1/2) | Occurs when team members with different perspectives (customer, development, testing) collaborate to identify acceptance criteria and subsequent tests in advance of implementing the corresponding functionality. |
| Acceptance Test Driven Development (2/2) | Acceptance tests represent the user's point of view and act as a form of requirements to descript how the system will function, as well as serve as a way of verifying that the system functions as intended. Acceptance tests are sometimes automated. |
| Adaptive Planning | An approach to planning where long-term plans are constantly reviewed and revised to account for new information learned during the course of a project. |
| Agile Manifesto | A statement of the values that underpin Agile Software Development. It was drafted from February 11th through 13th, 2001. |
| Anti-pattern | A commonly used, yet ineffective, process or practice. |
| Assumption | An Influencing factor that believed to be true but has not been confirmed to be accurate, or that could be true now but may not be in the future. |
| ATDD | Acceptance Test Driven Development |
| Backlog | An ordered list of options that represent changes to a solution. Various frameworks use backlogs to represent the changes for a given scope. |
| Backlog item | An element on a backlog that represents a potential change to a product. Backlog items can take the form of user stories, spikes, defects, infrastructure work, refactors, documents or other item types that a team finds useful in their context. |
| business goal | A state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively |
| business objective | An objective, measurable result to indicate that a business goal has been achieved |
| business rules | A specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions. |
| BDD | Behavior driven development |
| business value(1/2) | 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. |
| Business value (2/2) | In agile development, an output delivers business value when it increases or protects revenue or reduces or avoids costs for an organization. |
| change | The act of transformation in response to a need. |
| collaboration | The act of two or more people working together towards a common goal. |
| constraint | An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option. |
| context | The circumstances that influence, are influenced by, and provide understanding of the change. |
| context diagram | The highest level data flow diagram which represents the system in its entirety, as the area under study with external organizations, people, or systems as the source or target of data flows. |
| core concept model (business analysis) | One of six ideas that are fundamental to the practice of business analysis: Change, Need, Solution, Context, Stakeholder, and Value. |
| customer | A stakeholder who uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet. |
| customer representative | an individual who works with the team to represent the perspective of stakeholders who use or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet |
| data model | A diagram that describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation. |
| decision maker | Person or people responsible for making the final decision. |
| definition of done | A technique where the team agrees on, and prominently displays, a list of criteria which must be met before a backlog item is considered done. |
| definition of ready | A technique where the team agrees on, and prominently displays, a list of criteria which must be met before a backlog item is considered ready for the team to start delivery work. |
| delivery team | A cross-functional team of skilled individuals who bring a variety of expertise to bear on the process of building a software product. |
| design | A usable representation of a solution. |
| domain | The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem |
| elicitation | Iterative derivation and extraction of information from stakeholders or other sources. |
| ethnographic elicitation techniques | Iterative derivation and extraction of information from stakeholders or other sources by observing users in their work environment and looking at business processes from the perspective of the user. |
| examples | An approach to defining the behaviour of a system using realistic examples instead of abstract statements. Examples are often used to further describe user stories and are used both as guidance for development and testing. |
| experiments | Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact. |
| feature | A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders. |
| fibonacci scale | commonly used when sizing user stories, based on the Fibonacci Sequence – a series of numbers characterized by the fact that every number is the sum of the two preceding ones. Generally, the scale includes the following numbers: 0, 1, 2, 3, 5, 8, 13 |
| framework | A collection of specific practices and ideas that have been proven useful in a specific context that teams can use as a basis to create their own methodology |
| Horizon | A view of work within an organization with a level of granularity appropriate to the time frame being planned for and the nature of the feedback loops used. |
| initiative | A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s). |
| information radiator | A handwritten, drawn, printed, or electronic display which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information about their work at a glance. |
| iteration | A defined time period when increments of a product are developed and tested and made ready to deliver to the customer. |
| iterative planning | An approach to planning that intentionally allows for repeating planning activities, and for potentially revisiting the same plan to update it based on new information. Can be regular iterations or time-boxes. |
| methodology | A body of methods, techniques, procedures, working concepts, and rules used to solve a problem. |
| metric | A quantifiable level of an indicator measured at a specified point in time. minimal marketable feature |
| minimum viable product | A concept from Lean Startup that describes the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort. |
| model | A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding. |
| monitoring | Collecting data on a continuous basis from a solution in order to determine how well a solution is implemented compared to expected results. |
| MMF | minimal marketable feature. |
| MVP | minimum viable product |
| Need | A problem or opportunity to be addressed. |
| outcome | The change in the organization and changes in the behavior of stakeholders as a result of an initiative. |
| output | Anything that your team delivers as part of your initiative. This includes software, documentation, processes, and other things that tend to be measured in order to gauge how the initiative is going |
| persona | Fictional characters or archetypes that exemplify the way that typical users will interact with a product. |
| predictive planning (1/2) | An approach to planning that involves detailed analysis and planning at the beginning of the project for the duration of the project and then acting on that plan. |
| product (business analysis) | A solution or component of a solution that is the result of an initiative. |
| product box | A collaboration framework where a team and customers design a box for their product in order to determine the characteristics of a product that customers want to buy. |
| product differentiation statement | An expression of how a given product fills a particular consumer need in a way that its competitors don’t. |
| product owner | The role on the team that represents the interests of all stakeholders, defines the features of the product, and prioritizes the product backlog. |
| product roadmap | A visual representation of how a team plans to implement their product strategy over progressively longer time horizons. The roadmap is updated frequently, and reflects outcomes the team plans to realize rather than outputs the team plans to deliver. |
| progressive elaboration | The act of continually defining requirements with successively greater levels of detail as needed through the life of the product or the feature within a product. |
| relative estimation | estimate work effort by defining features with stories and then assigning points based on the estimated amount of effort required. Then points are compared against the team's velocity for an estimate of how much can be delivered in a particular iteration. |
| release planning | At the beginning of a project the team will create a high-level release plan. The team cannot possibly know everything upfront so a detailed plan is not necessary. |
| 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, and •the ship date for the releases. |
| requirement | A usable representation of a need. |
| 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. |
| rolling planning | Rolling planning is a technique whereby a team plans for an iteration for only the time period where they have reasonable certainty. As that time comes to an end the team plans out for another time period, determined by their level of certainty. |
| risk | The effect of uncertainty on the value of a change, a solution, or the enterprise. See also residual risk. |
| service level agreements | Formal agreements that contract level of service and performance. |
| solution | A specific way of satisfying one or more needs in a context. |
| stakeholder | A group or individual with a relationship to the change, the need, or the solution. |
| state diagram | An analysis model showing the life cycle of a data entity or class. |
| story mapping | A technique to facilitate the understanding of product functionality, the flow of usage, and to assist with prioritizing product delivery (such as release planning). |
| three amigos session | A gathering of the people with three primary perspectives to examine an increment of work before, during, and after development. Three amigos perspectives areas |
| time-box | An agreed upon period of time in which an activity is conducted or a defined deliverable is intended to be produced. |
| user story | A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. |
| value (business analysis) | The worth, importance, or usefulness of something to a stakeholder in a context. |
| value stream mapping | A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service. |
| wireframes | A two-dimensional illustration of a user interface that focuses on space allocation and prioritization of content, functionalities available, and intended behaviors. Wireframes typically do not include any styling, color, or graphics. |
| Story mapping output | product of story mapping is a story map, which describes a workflow of user stories. Story maps may break down user stories into tasks for each process and may represent these tasks based on priority. |
| Predictive planning (2/2) | Based on the assumption that the later a mistake is found, the more it will cost to fix it. This results in the desire to plan the entire project at the beginning of the project and avoid changes to the plan as much as possible. |
| Agile Business Analysis | The practice of business analysis in an agile context with an agile mindset. Focuses on maximizing business value. |
| 2 types of agile delivery planning | Iterative and Adaptive |
| Iterative planning | prioritizes and refines the work in short cycles designed to provide focus and increase the feedback and learning gained from stakeholders |
| Adaptive planning | involves the continuous change to long-term plans. Constant planning and analysis is used to prioritize and refine the work to be done to deliver the highest value |
| Seven principles of agile analysis | 1. See the Whole 2. Think as a Customer 3. Analyze to Determine What is Valuable 4. Get Real Using Examples 5. Understand What is Doable 6. Stimulate Collaboration and Continuous Improvement 7. Avoid Waste |
| Three Planning Horizons | 1. Strategy 2. Initiative 3. Delivery |
| Strategy Horizon | looks at all of the work being undertaken in an organization and is used to make decisions at the highest levels about what work should be funded, the approaches to be taken, the availability of skills and resources, and alignment with business goals. |
| Strategy Horizon - level of granularity | selecting which initiatives should be undertaken, how they will be funded, and how they will be monitored. |
| Strategy Horizon - feedback | How well business goals are being met |
| Initiative Horizon | looks at the work needed to produce a single product, either for internal use in the organization or customer facing. Each initiative should have clear goals which help to specific strategic outcomes |
| Initiative Horizon - level of granularity | related to the specific features the product will have and how these are divided into discrete pieces of business value. |
| Initiative Horizon - feedback | based on customer or user interaction with the product and value delivered. |
| Delivery Horizon | where work happens: implementation teams build discrete pieces of the product using iterative or adaptive and incremental techniques, working from a prioritized list based on business value as identified at the other horizons. |
Created by:
Nortons77
Popular Business sets