Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
A philosophical foundation for effective software development, the Agile Manifesto was created by representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation-driven, heavyweight software development processes. It reads, in its entirety, as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Twelve principles underlie the Agile Manifesto, including:
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcome
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Self-organizing teams
• Regular adaptation to changing circumstances
Agile Development Practices
Procedures and techniques used to conduct Agile software development. Although there is no canonical set of Agile practices, most Agile practitioners adopt some subset of Scrum and XP practices. Broadly speaking, any practice or technique that facilitates the values and principles set forth in the Agile Manifesto can be considered an Agile practice
Agile Project Management
The style of project management used to support Agile software development. Scrum is the most widely used Agile project management practice. XP practices also include practices that support Agile project management. Essential feature of Agile project management include:
• Iterative development cycles
• Self-organizing teams
• Multi-level planning
• Dynamic scope
• Frequent collaboration with customer and/or business sponsors
Agile Software Development
The development of software using Agile development practices and Agile project management. Features of Agile software development include a heavy emphasis on collaboration, responsiveness to change, and the reduction of waste throughout the development cycle. Agile software development (ASD) focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready.
Organizations with production dependencies across department boundaries run the risk of falling out of phase (or alignment). Alignment includes any actions or policies that exist so that a process or activity in one section of the organization is congruent with the organization’s or business unit’s governing mission. The lack of business/IT alignment is a chronic problem for many ogranizations and frequently the root cause of systemic software delivery failure. Agile development practices are designed to address many of the root causes of misalignment between IT and the business.
Application Lifecycle Management (ALM)
“Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance.” (Wikipedia)
When Agile software development is introduced into an organization it generally requires substantial changes in the organization’s ALM tools and policies, which are typically designed to support alternative methodologies such as Waterfall.
A collection of stories and tasks the Sprint team will work on at some point in the future. Either the Product Owner has not prioritized them or has assigned them lower priority. Teams or organizations may use the term “backlog” in one of the following four ways:
• Stories or tasks that are likely to be considered in the next iteration’s planning game.
• Stories or tasks that are definitely planned to be worked on in the next iteration (rather than just being available for consideration).
• Stories or tasks that are assigned to the current iteration, but are not being worked on, yet. As the team has time, these will be worked on after the higher priority items are completed.
• In a very fluid team, the planning game may assign more stories than can be done during the iteration. The backlog consists of stories and tasks that may slip into the next iteration.
A unit of work, usually a story or a task, listed on the project backlog.
Backlog Item Effort
Some Scrum practitioners estimate the effor tof product backlog items in ideal engineering days, but others prefer less concrete backlog effort estimation units. Alternative units might include story points, function points, or “t-shirt sizes” (1 for small, 2 for medium, etc). The advantage of more vague units is that they’re explicit about the distinction that product backlog item effort estimates are estimates of effort, not duration. Also, estimates at this level are rough guesses that should never be confused with actual working hours (Note that sprint tasks are distinct from product backlog items and task effort remaining is always estimated in hours)
Backlog grooming is both an ongoing process and the name for a meeting:
• The process of adding new user stories to the backlog, re-prioritizing existing stories as needed, creating estimates, and deconstructing larger stories into smaller stories or tasks.
• A meeting or ceremony that occurs regularly within a team’s iteration cycle. Scrum Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and tending to the backlog. Backlog grooming is the term favored by the Scrum Alliance, although Scrum co-founder Jeff McKenna and Australian CST Kane Mar prefer to call this ceremony Story Time.
Big Visible Charts
Big visible charts are exactly what you would think they would be: Big charts posted near the agile team that describe in different ways the team’s progress. Big visible charts not only can be useful tools for the team but also make it easier for any stakeholder to learn how the team is progressing. Big visible charts are an important tool for implementing the essential agile vaules of transparency and communication.
Any resource or process whose capacity is less than or equal to the demand placed on it, thus constraining the flow of work or information through the process.
“The duplication of objects under revision control (such as a source code file, or a directory tree) in such a way that the newly creeated objects initially have the same
Breaking the Build
When a developer adds changes to the source code repository that result in the failure of a subsequent build process, the developer has “broken the build.” Avoiding breaking the build is a commitment generally required by agile software developers and integral to the XP practice continuous integration.
The build is broken if the build process cannot successfully completed for any number of reasons including (but not limited to) failure to compile, compiling with unacceptable warnings, or the failure of any number of (usually) automated software tests. The more comprehensive the build process, the higher the threshold for breaking the build.
If a code submission does result in breaking the build, the developer should immediately remove the cause. If the build breaks but the immediate cause is not self-evident, a frequent practice of established agile development teams is to take immediate action to fix the build.
“The amount of variability in implementation makes it difficult to come up with a tight definition of a Build Process, but we would say that a Build Process takes source code and other configuration data as input and produces artifacts (sometimes called derived objects) as output. The exact number and definition of steps depends greatly on the types of inputs (Java versus C/C++ versus Perl/ython/Ruby source code) and the type of desire output (CD image, downloadable zip file or self-extracting binary, etc). When the source code includes a compiled language then the Build Process would certainly include a compilation and perhaps a linking step.”
A publicly displayed chart that depicts the total task hours remaining per day. It shows where the team stands regarding completing the tasks that comprise the backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours). To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an effective information radiator. A manual alternative to this is a physical task board. Ideally, the chart burns down to zero by the end of the sprint. If the team members are reporting their remaining task hours realistically, the line should bump up and down.
An informal term that includes all forms of value that determine the health and well-being of the firm in the long run. It expands the concept of value of the firm beyond economic value to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. In the context of agile development, it is what management is willing to pay for and a way to identify the value of “work” or a story.
Scrum slang for someone who is interested in a project but has no responsibility for working on a task in the active iteration. They may observe team meetings but cannot vote or talk.
“Any symptom in the source code of a computer program that indicates something may by wrong.” (Wikipedia)
Common code smells are ofen used to diagnose the quality of legacy code. Code smells generally indicate that the code should be refactored or the overall design should be reexamined.
Refers to development teams located and working in the same location. When possible colocation is desirable since it facilitates face-to-face collaboration, an important features of Agile software development. Contrast with distributed development team.
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.
The recipient of the output (product, service, information) of a process. Customers may be internal or external to the organization. The customer may be one person, a department, or a large group. Internal customers (outside of Information Technology) are sometimes called the “Business.”
Definition of Done
The criteria for accepting work as completed. Specifying these criteria is the responsibility of the entire team, including the business. Generally, there are three levels of “Done” (also known as Done-Done-Done):
• Done: Developed, runs on developer’s box
• Done: Verified by running unit tests, code review, etc.
• Done: Validated as being of deliverable quality with functional tests, reviews, etc.
However, the exact criteria for what constitutes “Done” varies to meet the specific needs of different organizations and initiatives. An important agile principle is to deliver (potentially) releasable software after every iteration. The definition of done is a key component of Agile project governance used to help teams comply with this principle.
“A design pattern is a general reusable solution to a commonly occurring problem in software design.” (Wikipedia)
Distributed Development Team
Refers to development teams that work on the same project but are located across multiple geographic locations or work sites. Distributed development teams are becoming the norm for today’s software projects. When colocation is not an option, distributed teams are faced with the challenge of keeping software projects on track and keeping remote developers engaged collaboratively. Agile development is more difficult for distributed teams and generally require that special practices are adopted that mitigate the inherent risks of distributed development.
Information model describing the application domain that creates a shared language between business and IT
Emergence is an attribute of complex systems. When applied to software development, it is the principle that the best designs and the best ways of working come about over time through doing the work, rather than being defined in advance as part of an over-arching specification or detailed project plan.
Empiricism is the principle that knowledge is acquired through our experience, which we obtain through our senses. Empiricism is the cornerstone of all scientific inquiry and the approach used by Agile teams to identify emergent requirements and incrementally develop software.
A very large user story that is eventually broken down into smaller stories. Epics are often used as placeholders for new ideas that have not been thought out fully or whose full elaboration has been deferred until actually needed. Epic stories help agile development teams effectively manage and groom their product backlog.
The process of agreeing on a size measurement for the stories or tasks in a product backlog. On agile projects, estimation is done by the team responsible for delivering the work, usually using a planning game.
Extreme Programming (XP)
A software development methodology adhering to a very iterative and incremental approach, Extreme Programming is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. XP consists of a number of integrated practices for developers and management – the original twelve practices of XP include Small Releases, On-site Customer, Sustainable Pace, Simple Design, Continuous Integration, Unit Testing, Coding Conventions, Refactoring Mercilessly, Test-Driven Development, System Metaphor, Collective Code Ownership, and Pair Programming.
Most successful Agile practioners adopt some subset of XP practices, often in conjunction with Scrum.
“A property of a system or module with respect to its response to failures. A fail-fast system is designed to immediately report at its interface any failure or condition that is likely to lead to failure.” (Wikipedia)
A coherent business function or attribute of a software product or system. Features are large and chunky and usually comprise many detailed (unit) requirements. A single feature typically is implemented through many stories. Features may be functional or non-functional; they provide the basis for organizing stories.
A sequence of numbers in which the next number is derived by adding together the previous two (e.g. 1, 2, 3, 5, 8, 13, 21, 34…). The sequence is used to size stories in Agile estimation techniques such as Planning Poker.
Continuous delivery of value to customers (vs. big-batch, big-release, big-bang).
In Scrum: Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily standup meeting. The ScrumMaster is charged with ensuring impediments are removed. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting
Inspect and Adapt
“Inspect and Adapt” is a slogan used by the Scrum community to capture the idea of discovering over the course of a project emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.
A period (from 1 week to 2 months in duration) during which the Agile development team produces an increment of completed software. All system lifecycle phases (requirements, design, code, and test) must be completed during the iteration and then (empirically) demonstrated for the iteration to be accepted as successfully completed. At the beginning of the iteration, the business or the product owner identifies the next (highest priority) chunk of work for the team to complete. The development team then estimates the level of effort and commits to completing a segment of work during the iteration. During the iteration, the team is not expected to change objectives or respond to change requests. However, at the front end of the next iteration the business or product owner is free to identify any new segment of work as the current highest priority.
Kanban is a tool derived from lean manufacturing and is associated with the branch of agile practices loosely referred to as Lean software development. Like a task board, Kanban visually represents the state of work in process. Unlike a task board, the Kanban constrains how much work in process is permitted to occur at the same time. The purpose of limiting work in process is to reduce bottlenecks and increase throughput by optimizing that segment of the value stream that is the subject of the Kanban. Task boards simply illustrate work in process without necessarily deliberately how much of work in process may occur at any given time, although the same effect may be achieved through the organic self-organization of the team.
A principle difference between Kanban and Scrum is that Scrum limits work in process through timeboxing (i.e. the sprint) and Kanban limits work in process by limiting how much work may occur at one time (e.g. N tasks or N storie
Lean Software Development
An adaption of Lean manufacturing principles and practices to the software development domain. Lean software development (also known as Lean-Agile) is focused on reducing (lean) waste and optimizing the software production value stream. In large part, the principles and practices of lean software development are congruent with other well-known Agile practices such as Scrum and extreme programming. However, in some cases they use different means to obtain the same end. For example, Scrum and Kanban (a lean technique) both reduce work in process (a lean waste) but use different techniques to accomplish this objective.
Minimum Marketable Features
The smallest set of functionality that must be realized in order for the customer to perceive value. A “MMF” is characterized by the three attributes: minimum, marketable, and feature. A feature is something that is perceived, of itself, as value by the user. “Marketable” means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty. A release is a collection of MMFs that can be delivered together within the time frame
“An Agile software development technique in which two programmers work together at one workstation. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. and the person reviewing the code is called the observer or navigator. The two programmers switch roles frequently.” (Wikipedia)
Pair programming is one of the original 12 extreme programming practices. As counter-intuitive as it may seem to the uninitiated, pair programming is more productive than two individuals working independently on separate task
Parallel development occurs whenever a software development project requires separate development efforts on related code bases. For example, when a software product is shipped to customers, a product development team may begin working on a new major feature release of the product, while a product maintenance team may work on defect corrections and customer patch releases of the shipped product. Both teams begin work from the same code base, but the code necessarily diverges. Frequently the code bases used in parallel development efforts must be merged at some future date, for example, to ensure that the defect corrections provided by the product maintenance team are integrated into the major release that the product development team is working on.
Scrum slang. Someone who is responsible for doing a task on an active iteration. It comes from the joke, “A chicken and a pig talk about breakfast. The chicken says, ‘Let’s have bacon and eggs.’ The pig replies, ‘That’s fine for you. You are just making a contribution, but I have to be fully committed.’” Pigs are actively involved in the project
“The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts.” (Wikipedia)
In XP, the planning game includes iteration (or sprint) planning and release planning. In scrum, sprint and release planning are two of the five levels of planning used in Agile projects.
“Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development.” (Wikipedia)
Broadly speaking, product refers to a collection of tangible and intangible features that are integrated and packaged into software releases that offer value to a customer or to a market. The term “product” is often used in Agile softwrae development to denote the software that is the subject of the iteration or release. As such, “product” is generally used interchangeably with other names for software release including “software release”, “system”, or “business application.”
Product Owner is one of the key roles in Scrum. The product owner is the primary business representative who represents the business stakeholders’ “voice of the customer” and the “voice of the business” to the sprint team. The responsibilities of the Product Owner include:
• Establishing, nurturing, and communicating the product vision
• Creating and leading a team of developers to best provide value to the customer
• Monitoring the project against its ROI goals and an investment vision
• Making decisions about when to create an official release
The product owner is a role rather than a position. Consequently, several people likely participate in the product owner role for larger projects.
A product vision is a brief statement of the desired future state that would be achieved through the project initiative. The product vision may be expressed in any number of ways including financial performance, customer satisfaction, market share, functional capability, etc. The product vision is typically the responsibility of executive sponsorship and is articulated to the Agile development team by the business and by the product owner, if the team is using Scrum.
Changing existing software code in order to improve the overall design. Refactoring normally doesn’t change the observable behavior of the software; it improves its internal structure. For example, if a programmer wants to add new functionality to a program, she may decide to refactor the program first to simplify the addition of new functionality in order to reduce technical debt.
Refactoring is one of the original twelve extreme programming practices and is considered critical for incrementally maintaining technical quality on Agile development projects.
The movement of a software product or system from development into production. One principle of Agile development is to focus on releasing software into productive use as soon as a minimum marketable feature set can be delivered, and then proceeding with frequent incremental releases. This is in contrast to alternative project approaches where most requirements are delivered in one “big bang” release.
It is desirable in Agile development to produce releasable software after every iteration (or sprint), even if the code is not actually put into production for use by end-users.
The release plan is a schedule for releasing software into productive use. Typical release plans include the key features to be delivered, along with corresponding release dates. Release plans may also expose key milestones or dependencies that parallel project activities. In agile development, release plans can be mapped back to the iterations (or sprints) that implement the released features.
Release planning refers to planning activities used to estimate when software will be released into product use. Activities include projecting the level of effort in terms of the number of iterations that will be necessary to deliver the desired features. This is typically done by extrapolating the development team’s performance on the basis of its velocity.
A release planning meeting that brings together all parties that have a stake in the outcome and have some kind of delivery responsibility to achieve the release is often necessary to produce a viable release plan. This is especially the case when several development and non-development production efforts are running in parallel with possible dependencies.
Release planning is one of the five levels of planning.
A timeboxed meeting held at the end of an iteration, or at the end of a release, in which the team examines its processes to determine what succeeded and what could be improved. The retrospective is key to an Agile team’s ability to “inspect and adapt” in the pursuit of “continuous improvement.” The Agile retrospective differs from other methodologies’ “Lessons Learned” exercises, in that the goal is not to generate a comprehensive list of what went wrong. A positive outcome for a retrospective is to identify one or two high-priority action items the team wants to work on in the next iteration or release. The emphasis is on actionable items, not comprehensive analysis. Retrospectives may take many forms, but there is usually a facilitator, who may or may not be a member of the team, and the process is typically broken down into three phases: data gathering, data analysis, and action items.
A framework for the iterative development of complex products, particularly software. Scrum is the most widely recognized Agile framework, and is compatible with other Agile practices like Extreme Programming. Scrum is comprised of a series of short iterations – called sprints – each of which ends with the delivery of an increment of working software. The framework is comprised of:
• Product Owner
• (Scrum) Team
• Daily Standup Meeting
• Sprint Planning Meeting
• Sprint Review
• Burndown charts
• Product backlog
• Sprint backlog
Sometimes the term Scrum is used interchangeably with the term Agile, but this is incorrect. Agile is not a fraemwork, but a broader set of values and practices, while Scrum is a specific framework that fits comfortably under the Agile umbrella.
The scrum team is a cross-functional group that is responsible for delivering the software or product. In Agile development, the team usually includes people skilled to understand customer requirements and conduct software design, coding and testing. Additional skills (e.g. UI design, usability, etc.) may also be included, especially when they are integral to the software release. The scrum team is encouraged to be self-organizing and to take collective responsibility for all work commitments and outcomes. Scrum teams respond to requirements (often presented as user stories) by collectively defining their tasks, task assignments, and level of effort estimates.
The ideal size for a scrum team adheres to the magic number seven plus or minus two rule.
The ScrumMaster is responsible for maintaining the Scrum process and the overall health of the team. The ScrumMaster assures that the team is fully functional and productive. The ScrumMaster performs this role by administering the Scrum ceremonies, facilitating the organic self-organization of the team, and removing any obstacles that may be impeding the team’s progress.
What the ScrumMaster is not:
• The ScrumMaster is not the task master, since the team is responsible for assigning its own tasks.
• The ScrumMaster is not the supervisor of the team, since the supervisor/subordinate relationship may impede the organic self-organization of the team.
A good ScrumMaster proactively anticipates problems, opportunities for improvement, and conducts pre-planning so the team can focus on delivering its sprint commitments. The ScrumMaster also keeps the team honest regarding its commitments and helps the team identify opportunities to improve collaboration.
In Scrum, when the Scrum roles are properly fulfilled there is no need for a traditional project manager to supervise the team. Nevertheless, many organizations choose to retain project managers, after they adopt Scrum, to perform functions that extend beyond the scope of the Scrum team functions.
Self-organization is a property of complex adaptive systems, whereby the organization of the system emerges over time as a response to its environment. In Agile development, particularly in Scrum, self-organization is a property of the agile development team, which organizes itself over time, rather than being ordered by an external force such as a project or development manager. Self-organization also reflects the management philosophy whereby operational decisions are delegated as much as possible to those who have the most detailed knowledge of the consequences and practicalities associated with those decisions.
A story or task aimed at answering a question or gathering information, rather than implementing product features, user stories, or requirements. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog
The Scrum term for an iteration. The sprint starts with a sprint planning meeting. At the end of the sprint there is a sprint review meeting, followed by a sprint retrospective meeting
Sprint Planning Meeting
Each sprint begins with a two-part sprint planning meeting, the activity that prioritizes and identifies stories and concrete tasks for the next sprint. For a one-month or four-week sprint, this two-part meeting should last eight hours; for a two-week sprint, it lasts about four hours. As a general rule of thumb, the number of weeks in a sprint multiplied by two hours equals the total length of the spring planning meeting.
• Part one of the sprint planning meeting is a review of the product backlog. This is when the product owner describes what needs to be built for the next sprint. During this part of the meeting, it is not uncommon for the team to discuss the sprint objectives with the product owner, and ask clarifying questions and remove ambiguity.
• During part two of the sprint planning meeting, the team decides how the work will be built. The team will begin decomposing the product backlog items into work tasks and estimating these in hours. The product owner must be available during this meeting but does not have to be in the room. The output of the second planning meeting is the Sprint Backlog.
A meeting held at the end of each sprint in which the Scrum team shows what they accomplished during the sprint; typically this takes the form of a demo of the new features. The sprint review meeting is intentionally kept very informal. With limited time allocated for Sprint review prep. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint
Anyone external to the team with a vested interest in the outcome of the team’s work.
“A daily team meeting held to provide a status update to the team members. The ‘semi-real-time’ status allows participants to know about potential challenges as well as coordinate efforts to resolve difficult and/or time-consuming issues… The meetings are usually timeboxed to 5-15 minutes, and are held standing up to remind people to keep the meeting short and to the point.” (Wikipedia)
A requirement, feature and/or unit of business value that can be estimated and tested. Stories describe work that must be done to create and deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation between the Scrum Team, Business Owners, and the Product Owner. Stories consist of the following elements:
• A description, usually in business terms
• A size, for rough estimation purposes, generally expressed in story points (such as 1, 2, 3, 5)
• An acceptance test, giving a short description of how the story will be validated
Tasks are descriptions of the actual work that an individual or pair does in order to complete a story. They are manageable, doable, and trackable units of work. Typically, there are several tasks per story. Tasks have the following attributes, and all tasks must be verified complete – not just “done”:
• A description of the work to be performed, in either technical or business terms
• An estimate of how much time the work will take (hours, days)
• An owner, who may or may not be pre-assigned
• An exit criteria and verification method (test or inspection)
• An indication of who will be responsible for the verification
A chart that presents, at minimum, “to do”, “in progress”, and “done” columns for organizing a team’s work. Some teams include their backlog as a column on the task board, while others limit it to work to be performed during the current iteration. Ideally, the task board is a physical thing, consisting of note cards or sticky notes affixed to a wall, although distributed teams may use an online task board application. The task board may illustrate tasks or other forms of work such as user stories. In Scrum, the task board is often used to illustrate the tasks for the current sprint, populated with tasks for the current sprint, while other Agile teams may populate it with user stories.
In agile software development, the team refers to the cross-functional group of people that have made a collective commitment to work together to produce the work product and improve their performance over time. In addition to software development and test roles, the team may include any skill set necessary to deliver the work product.
A term coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term. Whether or not to incur technical debt is a tradeoff decision that ideally is made in a deliberate manner at the point that work occurs.
“The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting function.” (Wikipedia)
In agile development, test automation is frequently used to automate unit tests, integration tests, and functional tests. Since the definition of done for most agile projects requires that code be thoroughly tested by the end of the iteration, test automation is critical if not necessary to obtain acceptable velocity. In addition, for most practical purposes, test automation is necessary to effectively apply coninuous integration and remain true to the commitment to not “break the build.”
Test-Driven Development (TDD)
“Test-Driven Development is a software development process that relies on the repetition of a very short develpment cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.” (Wikipedia)
Ken Beck is credited for having invented TDD, one of the orignal 12 XP practices
A timebox is a time period of fixed length allocated to achieve some objective. In agile development, iterations and sprints are examples of timeboxes that limit work in process and stage incremental progress. Timeboxes are often used to avoid over-investing in tasks such as estimating development tasks.
“A unit is the smallest testable part of a software system. In procedural programming, a unit may be an individual function or procedure.” (Wikipedia)
Comprehensive unit test coverage is an important part of software integrity and should be automated to support the incremental delivery requirements of agile software development teams. In most cases, unit testing is the responsibility of the developer.
Velocity measures how much work a team can complete in an iteration. Velocity is often measured in stories or story points. Velocity may also measure tasks in hours or an equivalent unit. Velocity is used to measure how long it will take a particular team to deliver future outcomes by extrapolating on the basis of its prior performance. This works in Agile development, when work is comprehensively completed after each iteration.
Voice of the Customer (VOC)
“Voice of the Customer (VOC) is a term used in business and Information Technology (through ITIL) to describe the in-depth process of capturing a customer’s expectations, preferences, and aversions. Specifically, the Voice of the Customer is a market research technique that produces a detailed set of customer wants and needs, organized into a hierarchical structure, and then prioritized in terms of relative importance and satisfaction with current alternatives.” (Wikipedia)
An editable intranet site where details of stories and tracking information may be recorded during development.
Work in Progress (WIP) AKA Work in Process
Any work that has not been completed but that has already incurred a capital cost to the organization. Any software that has been developed but not deployed to production can be considered a work in progress.
Source; Solutions IQ