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 BA Glossary
| Question | Answer |
|---|---|
| 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/3) | 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. |
| 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 is 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 | see 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. |
| BDD | See behavior driven development. |
| Business domain | See Domain. |
| 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 behaviour, shaping judgments, or making decisions. |
| 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. |
| 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 |
| 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. |
| done | See Definition of Done. |
| 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 (1/2) | A scale commonly used when sizing user stories that is based on the Fibonacci Sequence – a series of numbers characterized by the fact that every number after the first two is the sum of the two preceding ones. |
| 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. |
| goal | See business goal. |
| 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 (1/2) | 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. |
| 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 | A small, self-contained feature that can be developed quickly and delivers significant value to the user. |
| 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 | See minimal marketable feature. |
| MVP | See minimum viable product. |
| need | A problem or opportunity to be addressed. |
| objective | See business objective |
| 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. |
| planning horizon | See Horizon. |
| 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 product roadmap is updated frequently, 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 (1/2) | A way of estimating work effort by identifying features/requirements with stories and then assigning story points to stories. The cumulative story points represent the estimated amount of effort required to deliver the story. |
| 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. The release plan should address |
| 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 (1/2) | 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. Those perspectives are |
| 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. |
| user story mapping | See story mapping. |
| 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 require d 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 behaviours. Wireframes typically do not include any styling, color, or graphics. |
| acceptance test driven development (2/3) | These acceptance tests represent the user's point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. |
| acceptance test driven development (3/3) | In some cases the team automates the acceptance tests. |
| 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. |
| fibonacci scale (2/2) | In practice teams use a modified sequence that stops the pattern at larger numbers. Generally, the scale includes the following numbers |
| story mapping (2/2) | The output of the story mapping exercise is a product called 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. |
| relative estimation (2/2) | 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. |
| predictive planning (2/2) | Predictive planning is 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. |
| iterative planning (2/2) | These planning activities are repeated in some agile approaches in regular iterations or time-boxes. |
Created by:
calabar77
Popular Management sets