Gross Definitions: 144 Agile Terms You Simply Have To Know

"Gross ignorance is 144 times worse than ordinary ignorance" - Bennett Cerf

1. Acceptance Criteria: The conditions under which a piece of work may be held to be complete and fit for potential release.
2. Acceptance Test Driven Development (ATDD): A development approach in which acceptance criteria are validated by testing. The necessary tests are implemented first, and development work must then be done which is sufficient to satisfy them.
3. Actionable Metrics: Empirical measures which are taken in order to assess value, and which may be used to inspect and adapt a product and/or a development process so that better value can be delivered. Compare Vanity Metrics.
4. Adaptation: The modification of a product, role, event, or artefact in light of inspection. In an agile way of working, adaptation ought to occur as close as possible to the time and place of inspection in order to minimise waste.
5. Agile Coach: A suitably skilled person, such as a Scrum Master, who can teach, train, mentor, or otherwise communicate agile change and its associated ways-of-working to others. Compare Agile Sponsor.
6. Agile Sponsor: An authoritative person within an organisation who communicates the necessity for deep and pervasive change, and who thus ensures that an agile transformation and its associated coaching initiatives are able to overcome organisational gravity.
7. Agile Transformation: The process of realigning an organisation towards the timely and empirical delivery of emergent value, in order that innovative potential might be harnessed. The change required is typically deep and pervasive. See also Agile Coach, Agile Sponsor.
8. Anti-pattern: A behavioural or organisational pattern or practice which is contrary to an agile way of working, and which suggests the need for more appropriate patterns or practices.
9. Artefact: An input or output of an agile process. In Scrum there are three artefacts: the Sprint Increment, the Sprint Backlog, and the Product Backlog.
10. Automation: The elimination of manual work, particularly with regard to the building, integration, testing, and deployment of product increments.
11. Automated Build: The compilation and linking of system elements without need for manual initiation or intervention, typically in response to a trigger such as a code check-in or a timed event.
12. Automated Testing: The testing of system elements, including functional and integration tests, without need for manual initiation or intervention. The execution of an automated test harness may be triggered by the completion of an automated build. A high degree of test automation is usually needed to make regression testing practicable. See also: Regression Testing
13. Avatar: A motif, image, or other symbol which designates a particular team member, and which is attached to a representation of work in progress in order to communicate that the individual is helping to complete it.
14. Backlog: An ordered list of items to be worked on by one or more teams, and which thus allows requirements to be satisfied in a timely and effective manner.
15. Backlog Refinement: The process of adding detail, order, and estimates to items of inventory in a backlog. Items will have been refined to a sufficient degree once they are ready to be worked on. Refinement is best conducted by those who will eventually do the work.
16. Batch: A group of items drawn from a backlog which are processed jointly, rather than individually. Small batch sizes allow work to be processed comparatively quickly and for value to be evidenced earlier. Limiting inventory, such as work-in-progress, to a certain number of items is a common way of restricting batch size.
17. Behavior Driven Development (BDD): An approach to development in which the satisfaction of practical usage scenarios and their corresponding acceptance criteria is paramount. See also: Acceptance Test Driven Development.
18. Blocked: The state of a work item when it can no longer be progressed due to an impediment which team members are unable to resolve. A Scrum Master will pro-actively seek to remove impediments which block team progress.
19. Burn-down Chart: A chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart. See also: Burn-up chart.
20. Burn-up Chart: A chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.
21. Business as Usual (BAU): Work which is not temporary in nature, and which is thus not typical of a project. Ongoing product and service support, including maintenance tasks, are often considered to be BAU.
22. Cadence: A regular cycle of inspection and adaptation. Artefacts, progress towards a goal, engineering practices, and market conditions may be inspected and adapted on cadence. Scrum teams observe a daily cadence marked by a Daily Scrum in which progress towards a Sprint Goal is inspected, and the Sprint Backlog may be adapted accordingly. The Sprint itself is a longer cadence during which a product increment may be released, and the conditions and engineering practices in which it is delivered may be evaluated. See also: Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective.
23. Champion: A Development Team member who is competent to represent a parent organisation's stake in engineering practices and standards. Security considerations, data integrity, branding, and test quality may be significant to the wider organisation or its stakeholders.
24. Coherence: The quality of the relationship between certain work items which may make them worthy of consideration as a whole, such as a Minimum Viable Product, Minimum Usable Subset, or other feature worthy of release. A Sprint Goal should give coherence to those items planned from a Product Backlog into a Sprint Backlog.
25. Collaboration: The quality of teamwork which allows a goal to be focused on and achieved by self-organising team members, by means of their joint effort.
26. Commitment: The inviolable and indivisible purpose behind collaborative work. In Scrum, Development Teams will commit to a Sprint Goal, during Sprint Planning, and which will not change throughout the duration of the Sprint time-box.
27. Continuous Delivery: The automated elevation of increments of release quality into a production environment. See also: continuous deployment, continuous integration.
28. Continuous Deployment: The automated elevation of work done into successive environments which approach production quality. See also: automation, automated build, automated testing. See also: continuous delivery, continuous integration.
29. Continuous Integration: The automated integration of work done into an increment of potential release quality. See also continuous delivery, continuous deployment.
30. Cross Functional: The quality of a team which allows them to complete work-in-progress by themselves, and without recourse to skills or resources outside the team. Compare with Skills Silo.
31. Daily Scrum: A daily inspect-and-adapt event conducted by Scrum Development Teams, in which they re-plan their progress towards their Sprint Goal.
32. Defect: A non-conformance of system performance with expected results. A form of waste which can be minimised by test-driven development.
33. Definition of Done: Stipulated conditions which must hold for a product increment to be considered finished, and of release quality.
34. Definition of Ready: Stipulated conditions which must hold for a work item to be actioned by a team, such as the quality of its acceptance criteria or its degree of scope.
35. Dependency: The relationship between artefacts, roles, or items of work which may inhibit their progress unless they are decoupled, or those relationships are taken into consideration.
36. Development Team: Those persons who, by collaborative effort and shared commitment, may develop an increment of value and of usable quality. A Scrum Development Team ought to be cross-functional and should number between three and nine members.
37. DevOps: The bridging of development work and operational support responsibilities in a cross-functional team. A DevOps capability is typically facilitated through a high level of automation.
38. Emergence: The incremental process through which complex qualities are better understood and gradually brought into focus. In an agile way-of-working, an emergent system is understood by the inspection and adaptation of empirical evidence, including that presented by the incremental delivery of value, often on cadence.
39. Empiricism: The evaluation of a system in terms of real-world impact and the value it is observed to provide, rather than by an alternative or proxy measure. Compare with Vanity Metrics.
40. Empowerment: The removal of restrictions on a team’s ability to collaborate and self-organise, including dependencies and skill-silos, so that they can meet an agreed goal or commitment.
41. Engineering Practices: The ways-of-working used by a Development Team to build a product increment in an agile manner.
42. Engineering Standards: The best practices which one or more Development Teams will observe in order to create an increment of release quality.
43. Epic: A user story or requirement which aggregates multiple other such items in a way which gives them coherence.
44. Escalation: The raising of a problem, such as an impediment, to an authority which is in a position to resolve it. Agile teams ought to be self-organising and sufficiently empowered to render escalation beyond the team unnecessary. A Scrum Development Team may escalate impediments to their Scrum Master for resolution. 
45. Estimation: The sizing of work, typically on a backlog, by those who are likely to perform that work. In Scrum, estimation allows a Development Team to ascertain how much work it can plan into a Sprint, and for forecasts to be made regarding how much work is thought to remain at any given point.
46. Exploratory Testing: The testing of work with the intention of uncovering defects which have not yet been exposed by automated means. Exploratory testing is typically manual and ad-hoc in nature.
47. Fail Early: The elimination of future waste by calling a halt to an initiative which has failed to demonstrate empirical value, and before any further waste is allowed to accumulate.
48. Fibonacci Sequence: A sequence of numbers commonly used or approximated for estimation purposes, in which each successive number beyond the second number is the sum of the two prior numbers, viz: 1, 2, 3, 5, 8, 13. The use of this sequence reduces the opportunity for false precision when estimating large pieces of work.
49. Forecast: A plan or projection based on empirical evidence, such as the rate of work completed.
50. Huddle: See Daily Scrum.
51. Increment: A usable implementation of an emergent product which is made available at a certain point in time. In Scrum, product increments are held to be cumulative, such that the latest increment will incorporate the value of all prior increments.
52. Incremental Development: The provision of an emergent product or service by means of successive development efforts, often on cadence, each of which provides a usable increment of value.
53. Information Radiator: A mechanism through which timely and useful information can be pulled on-demand by interested observers, and relied on for its transparency and accuracy. The most common type of information radiator found in agile practice is a Scrum Board or Kanban Board.
54. Innovation: The process of discovering or creating new market opportunities and satisfying them. Such opportunities may become apparent through emergence, and their exploitation may require the use of agile practices. Innovation which compromises existing markets is sometimes referred to as being disruptive.
55. Inspection: The process of assessing the condition of a product, role, event, or artefact in response to a triggering condition, so that it may be adapted and improved. Inspection may be triggered by the detection of an error or by the completion of work; either condition may represent an opportunity to reflect and improve. In an agile way of working, adaptation ought to occur as close as possible to the time and place of inspection in order to minimise waste.
56. Integration: The combining of completed work items from various sources into an increment of demonstrable release quality. At scale, the deliverables of multiple teams may need to be integrated before a product increment can be released. See also: automation.
57. Inventory: Work which is being held in a batch, such as a backlog or as work-in-progress, and which is subject to depreciation until the value of that work is released. See also: batch.
58. INVEST Criteria: The qualities of a user story or similar item of inventory which make it independent of other items, negotiable as an element of scope, valuable to stakeholders, estimable by those doing the corresponding work, small enough to be completed by them in a timely manner, and testable in order to prove its fitness for release.
59. Iteration: A time-box of fixed duration and regular occurence during which one or more increments of value are developed and made available for immediate release, and at least one opportunity for inspection and adaptation is presented.
60. Just-in-Time: The synchronisation of demand with supply so that batch sizes are minimised, and waste caused by inventory depreciation is reduced.
61. Kaizen: Improvement, usually taken to mean improvement in a gradual sense by means of empiricism, transparency, inspection, and adaptation.
62. Kanban: A closed economy of production in which work in progress is represented by a finite number of tokens, and the delivery of value is optimised by inspection, adaptation, and the ongoing reduction of waste.
63. Kanban Board: An information radiator which shows items of inventory being processed in Kanban-fashion, typically by representing them by means of cards, and showing their progress through work stations in which value is added. Uneven flow and other forms of waste can thereby be highlighted and acted upon.
64. Latency: The time it takes for a work item, following its acceptance by a Development Team, to be delivered as a usable increment of value.
65. Lean Startup: An organisation developing a product, service, or business model which enables sustainable growth, and which minimises waste in order to do so before resources expire.
66. Leap-of-Faith: The time, money, or other resources which must be invested in a development effort before empirical proof of value is delivered. In Scrum, the leap-of-faith is minimised to one Sprint’s worth of investment.
67. Little’s Law: The relationship between latency, throughput, and work-in-progress, such that WIP = latency x throughput
68. Management by Exception: The empowering of teams to self-organise and otherwise operate within certain tolerances. If those tolerances are exceeded then management will be notified and only at that point will they become actively involved. A Scrum Master may notify management by exception if he or she is unauthorised or otherwise unable to resolve impediments which affect the team.
69. Metrics: The key indicators and measures which allow progress to be assessed, and for inspection and adaptation to occur. The best metrics are based on empirical evidence and allow improving action to be taken.
70. Minimum Usable Subset: The fewest work items which must be completed in order to have an increment which, when released, is usable by stakeholders for a coherent purpose.
71. Minimum Viable Product: Either a Minimum Usable Subset, or in Lean Startup terms, the smallest increment which must be released in order to frame and test an hypothesis about the value which really ought to be delivered.
72. Nexus: A collaborative group of Scrum Teams who work together on the same product, planning and drawing work from the same Product Backlog, and who create an integrated and tested increment of release quality with respect to a commonly observed Sprint cadence.
73. Non-Functional Requirements: Those requirements germane to a system’s scope which are held to be invariant, which cannot be prioritised in relation to functional requirements for incremental delivery, and which, being applicable to every increment, may be indicative of the system’s overarching qualities.
74. One Point One Card: A very simple estimation technique in which each item of backlog inventory is held to be of equivalent magnitude (in effect, one point). The use of this technique can encourage the refinement of small pieces of inventory which are less likely to be impeded, and which may thus allow value to be made available earlier. However, it may also encourage a technical focus which makes business prioritisation of such items difficult. Where this estimation technique is used, throughput and velocity can be expected to resolve to the same measure.
75. Operating Model: The model with reference to which an organisation delivers value to its stakeholders. In an agile way of working, an agile framework such as Scrum may be used to define an operating model or an essential part of one.
76. Organisational Gravity: The tendency of people within an organisation to revert to traditional ways-of-working in response to an agile transformation initiative, and to present defensive behaviours when faced with the expectation of such change. The strength of agile sponsorship is a critically important factor in overcoming organisational gravity. See also: agile transformation, agile sponsor.
77. Pair Programming: An engineering practice in which two Development Team members will collaborate in the same programming activity, constantly checking and assisting each other’s work, discussing design decisions, and providing mutual encouragement and immediate peer review.
78. Pattern: A common behaviour or way-of-working which can be abstracted and reused in order to improve agile practice.
79. Peer Review: An engineering practice in which a Development Team member will review the work done by another team member, in order to provide a quality check. Delay and depreciation can be reduced if this occurs in a pair programming context.
80. Personas: A personification of a system stakeholder, either real or imaginary, by means of which system requirements can be elicited and described.
81. Pivot: A significant adaptation to a new value proposition, architecture, technology, or market, in light of inspection and empirical evidence obtained, and which requires validation by a new MVP. Commonly associated with Lean Startup practices, a pivot ought to minimise any leap-of-faith assumptions regarding the adaptation.
82. Planning Poker: A relative estimation technique using playing cards enumerated with a Fibonacci-like sequence. Each member of the Development Team will get a set of cards, and will use them to indicate the relative size of the backlog items being considered. See also: product backlog refinement.
83. Potentially Releasable: The quality of an increment which asserts that no further work need be done for its use by stakeholders in the manner intended.
84. Prime Directive: A pre-condition which must hold for a Sprint Retrospective to be conducted, in which team members acknowledge each other’s competence to be there and agree to respect each other’s opinions without rancour. See also: Scrum values.
85. Product Backlog: A backlog placed under the stewardship of a Product Owner, who uses it to frame and order the scope of an emergent product so that maximum value can be delivered by one or more development teams.
86. Product Backlog Refinement: See backlog refinement.
87. Product Owner: The authoritative voice representing a product, and the person who is responsible for maximising the value it provides. The Product Owner is accountable to stakeholders for product value, and represents and balances their interests.
88. Proxy Product Owner: An authority to whom a Product Owner may choose to delegate certain responsibilities. Proxy Product Ownership has the potential to cloud authority regarding product scope and/or accountability for product value, and is thus sometimes considered to be an anti-pattern.
89. Pull: The demand exerted by consumers of value for completed work, and which encourages development teams to release usable increments at a sustainable pace and which maximises the value delivered.
90. Quality: The characteristics of a product increment or service which render it fit for use by stakeholders.
91. Quality of Service: The degree of quality which is appropriate for a particular service provided to stakeholders, such as may be defined by a service level agreement.
92. Ready: The state of a backlog item when it is capable of being brought into progress and worked on. See also: backlog refinement.
93. Refactoring: The re-organising of code, system components, or corresponding design elements to improve transparency and ease of understanding. Refactoring does not change the functional characteristics of the system.
94. Regression Testing: The execution of all of test cases which assert that a product is fit for use, including those test cases which verify the functionality delivered in earlier product increments.
95. Release: The delivery of a product or service increment into a production-quality environment, such that it is available for immediate use by stakeholders.
96. Release Plan: A forecast which indicates the increments of value which may reasonably be expected in the future. Stakeholders, or a representative authority such as a Product Owner, may make such forecasts based on the empirical evidence of delivery and the work which is currently thought to remain in a Product Backlog.
97. Relative Estimation: The sizing of backlog items in terms of their comparative scale. This contrasts to absolute estimation in terms of projected cost or likely time to complete. Relative estimation can be accomplished qualitatively, such as by T-Shirt Sizing (e.g. XS, S, M, L, XL, XXL) or quantitatively, such as by story points. See also: Planning Poker, Fibonacci sequence.
98. Requirements: The characteristics which a product or service is expected to demonstrate, including its functional scope, its non-functional properties, and its degree of quality. Where the complexity of a product or service domain is high, requirements may be emergent.
99. Scope: The functional and non-functional requirements of a product or service which are expected to be satisfied.
100. Scrum: A huddle of team members who have assembled temporarily in order to collaborate and solve a problem, or to otherwise reach a joint agreement (e.g. a Daily Scrum). The Scrum Framework is an agile development approach based on this technique, and which is used for building complex products.
101. Scrum Board: An information radiator which shows the progress of a team’s work as it is drawn, actioned, and completed from their Sprint Backlog. A Scrum board may show user stories and/or planned tasks, or both, or some other meaningful representation of the team’s work.
102. Scrum Master: The servant-leader for a Scrum Team, who removes impediments to their work, facilitates their progress towards the Sprint Goal, and coaches them and the wider organisation in the best use of the Scrum Framework.
103. Scrum of Scrums: A Scrum held between multiple Scrum Teams or their representatives, often for the purpose of ensuring that mutual dependencies are resolved and that product integration is not impeded.
104. Scrum Team: A self-organising team of professionals, consisting of a Scrum Master, Product Owner, and a Development Team, who deliver increments of value every Sprint and who inspect and adapt their progress.
105. Scrum Values: The characteristics which Scrum Team members seek to internalise and demonstrate as a cultural norm, including Commitment, Focus, Respect, Openness, and Courage. See also: prime directive.
106. Self-Organisation: The quality of a team which allows it to inspect and adapt its behaviours, without external guidance, so that a goal or purpose can be met. A self-organising team must be sufficiently cross-functional in terms of the skills it incorporates for planned work to be done. Team members may exhibit a degree of cross-skilling so that each is capable of doing more than one kind of activity.
107. Skills Silo: A constraint upon team self-organisation which restricts individual team members to performing only one type of activity.
108. Sponsorship: The momentum provided by stakeholders for implementing change across an organisation. Agile transformation typically requires deep and pervasive change, and a correspondingly strong sponsorship which is communicated across multiple levels. See also: organisational gravity.
109. Sprint: A time-box of no more than one calendar month during which a Scrum Team will frame a Sprint Goal, and satisfy that goal by delivering a product increment of release quality. Sprints occur on a regular cadence and permit the inspection and adaptation of progress.
110. Sprint Backlog: A forecast of the work a Development Team plans to do in order to meet an agreed Sprint Goal. The backlog may be revised during the Sprint in order to better meet the Goal.
111. Sprint Goal: The purpose for conducting a Sprint, framed and agreed during Sprint Planning between the Development Team and the Product Owner. A Sprint Goal will give coherence to the Product Backlog Items selected and planned into the Sprint Backlog. In order for the Sprint Goal to be met, a corresponding increment of value must be developed and made available for release.
112. Sprint Planning: The act of negotiating a coherent selection of Product Backlog Items into an achievable Sprint Backlog of work, and the framing of a corresponding valuable Sprint Goal. A Sprint Plan must be agreed by the Development Team and the Product Owner.
113. Sprint Retrospective: The inspection and adaptation of a Scrum Team’s way-of-working, at the end of a Sprint, so that future Sprints might be improved. The whole Scrum Team is expected to participate. See also: prime directive.
114. Sprint Review: The inspection and adaptation of a Product Increment and the Product Backlog, at the end of a Sprint, so that the characteristics of the product can be evaluated and better understood.
115. Sprint Zero: A common anti-pattern in which a false Sprint is conducted for project initialisation purposes, and without the delivery of an increment of value. A Sprint must always deliver an increment of value, no matter how small.
116. Stakeholder: A party with an interest in a Development Team’s output. In the Scrum Framework, product stakeholder interests are represented by a Product Owner.
117. Stand-up: See Daily Scrum.
118. Station: A discrete point during the flow of work-in-progress at which value is added. Stations may include test authoring, development, review, and integration. Clear stations can improve transparency over work-in-progress and expose irregularities in flow and other instances of waste. An efficient, self-organising team will reduce skill-silos so that members can move freely over stations and smooth the progress of work.
119. Stewardship: The demonstration by a team member that he or she is a responsible custodian. A Product Owner should demonstrate good stewardship of the Product Backlog, while a Scrum Master should demonstrate good stewardship of the Development Team and its implementation of the Scrum Framework.
120. Stop-the-line: An event which triggers immediate inspection-and-adaptation once a problem is detected, and which stops the problem from compounding. Work-in progress is suspended until remedy; the team will focus on providing that remedy and on eliminating the chance of the problem recurring. The ability of self-organising team members to halt work and correct errors in this manner is instrumental in limiting waste.
121. Story Mapping: The correlation of user stories to epics, features, and/or time-boxed opportunities for delivery, such as Sprints. Story mapping techniques can be used to frame Minimum Viable Products or Minimum Usable Subsets, or to propose tentative Sprint Goals. See also: backlog refinement.
122. Story Points: A measure used to estimate the relative size of backlog items, such as user stories. See also: relative estimation, Planning Poker, Fibonacci sequence.
123. Studio: A creative environment within which the agile delivery of value is fully supported. Stakeholders who wish to use the studio must agree to its terms of engagement.
124. Sustainable Pace: The quality of a team to work in a predictable manner at a regular cadence, such that useful stakeholder forecasts can be made regarding progress through a backlog of work.
125. Task Board: An information radiator showing the breakdown of work into technical tasks, and the progress of that work over various stations towards completion. See also: Scrum board.
126. TDD: Test Driven Development. The authoring of a test prior to the development of a capability which satisfies the condition. The test case can be assumed to fail when first executed. If it passes then it suggests either an error in the test, or the prior existence of a satisfactory capability. Enough development work is then done in order to ensure that the test passes. The code may then be refactored, and the test relied on to make sure that functionality has not been compromised. Also known as Red-Green-Refactor. See also: refactoring.
127. Team: A collaborative group of people with a joint sense of purpose, and who are able to demonstrate teamwork. As well as a Scrum Master and a Product Owner, a Scrum Team will further contain a Development Team.
128. Technical Debt: The longer-term consequence of poor design decisions. Technical debt is often incurred for the sake of expediency. A robust Definition of Done is instrumental in keeping technical debt under control.
129. The Three C’s: Card, Conversation and Confirmation. The three essential properties of a user story, which may be written on a “card". A user story is not a requirement, but rather a placeholder for one or more “conversations” which are held in order to satisfy the requirement. The implementation of the requirement must then be “confirmed”, such as by means of validated acceptance criteria or the successful execution of corresponding tests.
130. Three Questions: The planning considerations which each member of a Scrum Development Team must elicit during a Daily Scrum: namely, what they did yesterday to help the team meet the Sprint Goal, what they intend to do today to help meet that goal, and any impediments to their doing so.
131. Throughput: The rate at which increments of value are delivered by a Development Team.
132. Time-box: A period of fixed maximum duration in which team activities may be carried out. In Scrum there are five time-boxed events: Sprint Planning, the Daily Scrum, the Sprint Review, the Sprint Retrospective, and the Sprint itself which is a time-box containing all other events.
133. Tolerances: The remit within which a self-organising team is empowered to operate. See also: management by exception.
134. Transparency: The degree of openness which is afforded to those who have a stake in a process. A transparent process is of critical importance to team members if they are to be able to inspect and adapt it. Transparency, along with inspection and adaptation, is fundamental to an agile way-of-working.
135. T-Shirt Sizing: A relative estimation technique which uses qualitative measures rather than quantitative ones to assert the projected size of backlog items. Typical sizes include XS, S, M, L, XL, and XXL. The use of T-Shirt sizing may make the elicitation of metrics, such as a burn-down chart, difficult unless they are mapped to a numerical scheme such as story points. See also: relative estimation.
136. Unit Testing: The authoring and execution of test cases which verify the functional correctness of specific units of code, such as functions or methods and their modules or classes. See also: TDD.
137. Usability Testing: The verification of system functionality by end-users or their representatives, thereby increasing the degree of assurance that an increment will prove to be of usable quality should it be released.
138. User Story: A placeholder for one or more conversations about a possible requirement. User stories are commonly used to represent the functional characteristics of a system from the perspective of an end-user, and will assert one or more acceptance criteria. A Product Backlog may consist largely or entirely of user stories. See also: The Three C’s, acceptance criteria, INVEST.
139. Value: The quality of a product or service which makes an investment in it worthwhile. Stakeholders in products or services can have different perspectives regarding the value which ought to be provided. A Product Owner will represent and arbitrate those interests, and seek to maximise the value delivered. A Product Owner has authority over what value means for a product.
140. Value Stream: The flow of work-in-progress across discrete stations where value is added. A product or service may incorporate one or more value streams. Development Teams may restrict their work to one value stream at a time in order to achieve focus and reduce waste.
141. Vanity Metrics: Measurements which are taken to show progress or value in the best possible light, and which thus fail to provide adequate transparency for the purposes of inspection and adaptation. Compare with actionable metrics.
142. Velocity: The rate at which work, expressed in terms of work items which have been relatively sized, is completed by a Development Team. In Scrum, a common measure of velocity is the number of story points which are, on average, reduced from the Product Backlog each Sprint.
143. Waste: The avoidable loss of value in a development and delivery process. Seven wastes are frequently attested for: transport costs (i.e. the handover of work), the cost of maintaining concurrently held inventory, the cost of moving work-in-progress around unnecessarily, time spent waiting and being unproductive, overproduction, the over-engineering of work, and depreciation.
144. Work in Progress: The work which has been accepted by a team and is pending completion. The limitation of WIP is generally desirable in order to improve throughput and to limit depreciation. See also: Little’s Law.