IT Project Management Glossary and Terminology
IT project management terms you should know.
This glossary will help your IT project teams standardize on frequently used project management terms, from critical path to work breakdown structure to scrum.
Acceptance Testing
Acceptance testing is a validation activity conducted to determine whether or not a system satisfies its acceptance criteria. It is the last phase of the software testing process.
Agile
A conceptual framework for undertaking software projects. Agile methods are a family of development processes, not a single approach to software development.
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 Manifesto
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.
Agile Methodology
An agile methodology is an adaptive systems development lifecycle methodology that delivers software in incremental chunks known as iterations or sprints. In agile development, time is fixed, and scope is allowed to float from one iteration to another based on the team’s user story progress. An agile methodology is best used when requirements are not well defined.
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.
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.
Alignment
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 organizations 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.
ASAP and ALAP
As Soon As Possible and As Late As Possible, respectively. A method of determining if tasks should start as soon as all prerequisites have been beet (ASAP) or as late as possible (ALAP) without delaying the completion of a project.
Assumption
There may be external circumstances or events that must occur for the project to be successful (or that should happen to increase your chances of success). If you believe that the probability of the event occurring is acceptable, you could list it as an assumption. An assumption has a probability between 0 and 100%; that is, it is not impossible that the event will occur (0%), and it is not a fact (100%) — it is somewhere in between. Assumptions are important because they set the context in which the entire remainder of the project is defined. If an assumption doesn’t come through, the estimate and the rest of the project definition may no longer be valid.
Backlog
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.
Backlog Grooming
Backlog grooming is 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. Rather than grooming the backlog sporadically throughout an iteration, the team may hold a backlog grooming session once per iteration. 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, and still others call this Backlog Refinement. The Backlog Grooming session is one of the five Scrum ceremonies. The other Scrum ceremonies are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Backlog Item
A unit of work, usually a story or a task, listed on the project backlog.
Backlog Item Effort
Some Scrum practitioners estimate the effort of 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).
Balanced Scorecard
A performance management tool which began as a concept for measuring whether the smaller-scale operational activities of a company are aligned with its larger scale objectives in terms of vision and strategy.
Baseline
A baseline is an approved configuration item, for example a project plan that has been signed off for execution. The baseline records the planned costs, schedule and technical requirements against which a project is measured.
Behavior Driven Development
Behavior driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read.
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.
Bottleneck
A bottleneck is a sort of congestion in a system that occurs when workload arrives at a given point more quickly than that point can handle it. It is metaphorically derived from the flowing of water through a narrow mouthed bottle where the flow of water is constrained by the size of its neck.
BOSCARD
A strategic planning tool used to provide the terms-of-reference for new projects. The BOSCARD acronym stands for Background, Objectives, Scope, Constraints, Assumptions, Risks and Deliverables. These headings are commonly found in terms-of-reference and project initiation documents.
Branching
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 content as the original, but can evolve independently of the original.
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.
Bugs
A software bug is a problem causing a program to crash or produce invalid output. It is caused by insufficient or erroneous logic and can be an error, mistake, defect or fault.
Build – Measure – Learn
The rapid experiment and learning cycle in LSU that permits us to rapidly validate assumptions and potentially fail fast
Build Process
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.
Business Case
A document recording the justification for starting a project. It describes the benefits, costs and impact, plus a calculation of the financial case.
Burndown Chart
A burn down chart is a graphical view of the remaining work left versus the time in an iteration. A project backlog or hours can be expressed on the vertical axis, while time is indicated on the horizontal axis. A burn down chart is often used to determine when work will be completed on a project or an iteration.
Burnup Chart
Representation of the amount of stories completed, with points plotted on an X and Y axis that map an upward trend of work completed until reaching 100%.
Business Value
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.
CAPEX
Capital Expenditure (CAPEX) is the amount a company spends to buy fixed assets, or to add to the value of an existing fixed asset with a useful life that extends beyond the taxable year.
CAPM
Certified Associate in Project Management (CAPM) is a certification in project management managed by the Project Management Institute in accordance with their published ANSI standard A Guide to the Project Management Body of Knowledge, shortened to PMBOK Guide.
Certified ScrumMaster
Someone who is acting in the role of ScrumMaster on a Scrum team and who has attended a two-day Certified ScrumMaster (CSM) class to obtain certification.
Change Control
The practice of identifying, documenting, approving and carrying out changes within a project.
Charter
Before you start a project, it is important to know the overall objectives of the project, as well as the scope, deliverables, risks, assumptions, project organization chart, etc. The project definition (or charter) is the document that holds this relevant information. The project manager is responsible for creating the project definition. The document should be approved by the sponsor to signify that the project manager and the sponsor are in agreement on these important aspects of the project.
Chicken
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.
Client
The person or group that is the direct beneficiary of a project or service is the client / customer. These are the people for whom the project is being undertaken (indirect beneficiaries are stakeholders). In many organizations, internal beneficiaries are called “clients” and external beneficiaries are called “customers,” but this is not a hard and fast rule.
Code Smell
Any symptom in the source code of a computer program that indicates something may by wrong.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.
Colocation
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.
Constraints
Constraints are limitations that are outside the control of the project team and need to be managed around. They are not necessarily problems. However, the project manager should be aware of constraints because they represent limitations that the project must execute within. Date constraints, for instance, imply that certain events (perhaps the end of the project) must occur by certain dates. Resources are almost always a constraint, since they are not available in an unlimited supply.
Continuous Integration
Continuous Integration (CI) is a eXtreme Programming (XP) practice where members of a delivery team frequently integrate their work (e.g. hourly, or at least once daily). Each integration is verified by an automated build, which also performs testing, to detect any integration errors quickly and automatically. The main goal of CI is to avoid what is commonly called integration hell. The principle benefits of CI are significantly reduced integration problems and better team coordination leading to higher-quality software being released more rapidly than in traditional software development environments.
Cost Benefit Analysis
The cost benefit analysis is used to show the expected benefits of a project are sufficient to warrant the cost of carrying it out. Monetary units are usually used for the comparison.
Cost Variance
The cost variance (CV) is used to measure the cost difference between a project’s earned value (EV) and the actual cost (AC) to deliver progress to date (CV = EV – AC). In application, positive CVs indicate the project is under budget, since it is delivering more value than incurring cost. If the project has a negative CV, it is over budget. Even positive CVs should be examined for root cause.
Critical Chain Project Management (CCPM)
A method of planning and managing projects that puts more emphasis on the resources needed to carryout project tasks. It is the Theory of Constraints (TOC) applied to projects.
Critical Path
The critical path is the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. It is the longest duration path through the workplan. If an activity on the critical path is delayed by one day, the entire project will be delayed by one day (unless another activity on the critical path can be accelerated by one day).
Critical Path Method (CPM)
A technique used to predict project duration by analyzing which sequence of activities has the least amount of scheduling flexibility.
Critical Success Factor
A factor identified as essential to achieving a successful project.
Cross-Functional Team
Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.
Customer
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.”
Daily Standup
A Daily Standup is a whole team meeting that happens at the same time every day that usually lasts 15 minutes or less. The meeting is designed to allow the entire team to synchronize with each other and to understand the flow and challenges of the development process. Each team member should provide the following information: what did I do yesterday, what am I planning to do today, and what impediments do I currently have?
Definition of Done
The criteria for accepting work as completed. Specifying these criteria is the responsibility of the entire team, including the business.
Deliverable
A deliverable is any tangible outcome that is produced by the project. All projects create deliverables, which can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are produced as a consequence of executing the project and are usually needed only by the project team. External deliverables are created for clients and stakeholders. Your project may create one or many deliverables.
Delphi Technique
A method used to estimate the likelihood and outcome of future events. A group of experts exchange views, and each individually gives estimates and assumptions to a facilitator who reviews the data and issues a report. This process continues until consensus is reached.
Dependency
A prerequisite to a task being able to start.
Design Pattern
A design pattern is a general reusable solution to a commonly occurring problem in software design.
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.
Domain Model
Information model describing the application domain that creates a shared language between business and IT.
Done
Also referred to as “Done Done”, this term is used to describe all the various tasks that need to happen before a story is considered potentially releasable.
Duration
How long a task takes, or is planned to take.
Earned Value
A measure of the value or cost of progress on a task or project. If a task is expected to cost $100, and it is 40% complete, it is said to have an Earned Value of %40. The Earned Value of an entire project is the sum of the earned values of all its tasks.
Emergence
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
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.
Epic
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.
Estimating
Estimating uses a number of tools and techniques to produce estimates. An estimate is an approximation of a projects timescale and cost that is refined throughout the project.
Estimation
The process of agreeing on a size measurement for the stories, as well as the tasks required to implement those stories, in a product backlog.
Executive Sponsor
The person who has ultimate authority over the project. The executive sponsor provides project funding, resolves issues and scope changes, approves major deliverables, and provides high-level direction. He or she also champions the project within the organization. Depending on the project and the organizational level of the executive sponsor, he or she may delegate day-to-day tactical management to a project sponsor. If assigned, the project sponsor represents the executive sponsor on a day-to-day basis and makes most of the decisions requiring sponsor approval. If the decision is large enough, the project sponsor will take it to the executive sponsor.
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 practitioners adopt some subset of XP practices, often in conjunction with Scrum.
Fail-Fast
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.
Feature
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.
Feature Creep
Feature creep occurs when a software becomes complicated and difficult to use as a result of too many features.
Fibonacci Sequence
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.
Float
The time a task can be delayed without delaying the project. Tasks on the critical path have no float.
Flow
Continuous delivery of value to customers (vs. big-batch, big-release, big-bang).
Functional Manager
The functional manager is the person you report to within your functional organization. Typically, this is the person who does your performance review. The project manager may also be a functional manager, but he or she does not have to be. If your project manager is different from your functional manager, your organization is probably utilizing matrix management.
Gantt Chart
A Gantt chart is a bar chart that depicts activities as blocks over time. The beginning and end of the block correspond to the beginning and end-date of the activity.
Impediment
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.
Issue
An issue is a major problem that will impede the project’s progress and that can’t be resolved by the project manager and project team without outside help. Project managers should proactively deal with issues through a defined issues management process.
Iteration
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
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. 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 stories).
Lean
Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System and is a set of techniques and principles for delivering more values with the same or less resources by eliminating waste across organizations and business processes
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.
Lifecycle
Lifecycle refers to the process used to build the deliverables produced by the project. There are many models for a project lifecycle. For software development, the entire lifecycle might consist of planning, analysis, design, construct/test, implementation, and support; this is an example of a “waterfall” lifecycle. Other lifecycles include iterative development, package implementation, and research and development. Each of these lifecycle models represents an approach to building on your project’s deliverables. (Read: Project managers need to understand lifecycle work)
Link
A prerequisite to a task being able to start.
Logic Network
A diagram showing the sequence of activities in a project across time. It shows which activity logically precedes or follows another activity. It can be used to identify the milestones and critical path of a project.
Milestone
A milestone is a scheduling event that signifies the completion of a major deliverable or a set of related deliverables. A milestone, by definition, has duration of zero and no effort. There is no work associated with a milestone. It is a flag in the workplan to signify that some other work has completed. Usually, a milestone is used as a project checkpoint to validate how the project is progressing. In many cases there is a decision, such as validating that the project is ready to proceed, that needs to be made at a milestone.
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.
Minimum Viable Product (MVP)
Potentially confusing, the strict Lean Startup definition is the smallest thing we can test to enable one cycle of the build – measure – learn loop. As opposed to Minimum Marketable Feature (MMF) that is the smallest thing that delivers a user value.
Monte Carlo Simulation
The Monte Carlo Simulation is a technique used to estimate the likely range of outcomes from a complex process by simulating the process under randomly selected conditions a large number of times.
MoSCoW
A prioritization method is used to decide which project requirements must be implemented first and which come later or will not be implemented at all. MoSCoW stands for Must, Should, Could, Would. The o’s are added to make the acronym pronounceable.
Murphy’s Law
The law that says; “If anything can go wrong, it will” named after Capt. Edward A Murphy, an engineer working on US Air Force Project MX981 in 1949.
NPV
Net Present Value (NPV) is an estimate that helps organizations determine the financial benefits of long-term projects. NPV compares the value of a pound today to the value of that same pound in the future, taking inflation and returns into account.
Objective
An objective is a concrete statement that describes what the project is trying to achieve. The objective should be written at a low level, so that it can be evaluated at the conclusion of a project to see whether it was achieved. Project success is determined based on whether the project objectives were achieved. A technique for writing an objective is to make sure it is Specific, Measurable, Attainable/Achievable, Realistic, and Timebound (SMART).
P3M3
P3M3, also known as the Portfolio, Program and Project Management Maturity Model is a reference guide for structured best practice. It breaks down the broad disciplines of portfolio, program and project management into a hierarchy of Key Process Areas (KPAs). P3M3 is owned by the Office of Government Commerce (OGC).
Pair Programming
Pair programming is 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. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.
Parallel Development
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.
Pareto Principle
Named after Italian economist Vilfredo Pareto, the Pareto Principle is the idea that by doing 20% of the work you can produce 80% of the benefit of doing the whole job. Or for quality improvement, most problems are produced by a few key causes.
PERT Chart
A tool used to schedule, organize and co-ordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a method developed by the United States Navy in the 1950s to manage the Polaris submarine missile program. Also known as a precedence diagram, a network chart and logic diagram.
PEST Analysis
A strategic planning tool used to evaluate the impact Political, Economic, Social, and Technological factors might have on a project. It involves an organization considering the external environment before starting a project.
Pig
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.
Pirate Metrics
A set of metrics designed to support LSU analytics and validation. AARRR is short for Acquisition, Activation, Retention, Referral, Revenue
Planning Game
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. 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
Planning Poker is an estimation game created by Mike Cohn of Mountain Goat Software. Planning Poker is used to estimate individual user stories as a team activity. The team gathers and reviews user stories one at a time. As stories are presented, the team discusses the user story and provides an estimate of the work from their own deck of cards. All estimates are presented and discussed until the team arrives at a consensus.
PMBOK
Owned by the Project Management Institute (PMI) the Project Management Body of Knowledge (PMBOK) is a collection of processes and knowledge areas accepted as best practice within the project management discipline.
PMP
Project Management Professional (PMP) is a globally recognized certification in project management. It is managed by the Project Management Institute and is based on the PMP Examination Specification published by PMI in 2005. Most exam questions reference to PMI’s ANSI standard A Guide to the Project Management Body of Knowledge, shortened to PMBOK Guide.
Portfolio Management
The co-ordinated management of a portfolio of projects to achieve a set of business objectives.
Product
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 software 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 Backlog
Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. The requirements are listed on the backlog in priority order and maintained by the product owner.
Product Owner
The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner.
Product Vision
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.
Program
A program is the umbrella structure established to manage a series of related projects. The program does not produce any project deliverables — the project teams produce them all. The purpose of the program is to provide overall direction and guidance, to make sure the related projects are communicating effectively, to provide a central point of contact and focus for the client and the project teams, and to determine how individual projects should be defined to ensure that all the work gets completed successfully.
Program Manager
A program manager is the person with the authority to manage a program. (Note that this is a role. The program manager may also be responsible for one or more of the projects within the program.) The program manager leads the overall planning and management of the program. All project managers within the program report to the program manager.
Project
A collection of tasks to accomplish a significant goal.
Project Baseline
The project baseline is used to establish the original set of budget and schedule estimates based on the approved project scope prior to project execution. Effective project managers compare the project baseline to the current project status to determine specific cost or schedule variances.
Project Definition
Before you start a project, it is important to know the overall objectives of the project, as well as the scope, deliverables, risks, assumptions, project organization chart, etc. The project definition (or charter) is the document that holds this relevant information. The project manager is responsible for creating the project definition. The document should be approved by the sponsor to signify that the project manager and the sponsor are in agreement on these important aspects of the project.
Project Management
The process of managing the schedule, costs, and assignments of a project
Project Management Office
The Project Management Office (PMO) is an organization within a company that develops and enforces project management processes, tools, and techniques. A PMO may form at a program level, a department level, or at an enterprise level. A PMO typically provides support for program or portfolio governance, project portfolio management, resource management, and issue and risk management.
Project Manager
The project manager is the person with the authority to manage a project. The project manager is 100% responsible for the processes used to manage the project. He or she also has people management responsibilities for team members, although this is shared with the team member’s functional manager. The processes used to manage the project include defining the work, building the workplan and budget, managing the workplan and budget, scope management, issues management, risk management, etc.
Project Phase
A phase is a major logical grouping of work on a project. It also represents the completion of a major deliverable or set of related deliverables. On an IT development project, logical phases might be planning, analysis, design, construct (including testing), and implementation.
Project Plan
The project plan (not to be confused with the project schedule) is the document that describes the processes, tools, and techniques used to manage and control the project. Common processes include specific project level processes such as change management, issue management, risk management, document management, and time management for project schedule updates.
Project Schedule
The project schedule is commonly associated with Microsoft Project or a similar scheduling tool. The project schedule is the series of tasks with durations, resources, and specific dependencies that forecasts the project end date.
Project Sponsor
The person who has ultimate authority over the project. The executive sponsor provides project funding, resolves issues and scope changes, approves major deliverables, and provides high-level direction. He or she also champions the project within the organization. Depending on the project and the organizational level of the executive sponsor, he or she may delegate day-to-day tactical management to a project sponsor. If assigned, the project sponsor represents the executive sponsor on a day-to-day basis and makes most of the decisions requiring sponsor approval. If the decision is large enough, the project sponsor will take it to the executive sponsor.
Project Team
The project team consists of the full-time and part-time resources assigned to work on the deliverables of the project. They are responsible for understanding the work to be completed; completing assigned work within the budget, timeline, and quality expectations; informing the project manager of issues, scope changes, and risk and quality concerns; and proactively communicating status and managing expectations.
RACI Chart
A RACI chart is a matrix of all the activities or decision making authorities undertaken in an organization set against all the people or roles. At each intersection of activity
and role it is possible to assign somebody Responsible, Accountable, Consulted or Informed for that activity or decision.
RAID Log
A RAID Log is a simple project management tool, often in the form of a spreadsheet, used to track Risks, Assumptions, Issues and Dependencies.
Refactoring
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.
Release
A release is a set of working software delivered to the business customer resulting from a set of iterations. During release planning, teams will review a product backlog to organize user stories into the specific releases and iterations that deliver a functional product to the business customer.
Release Plan
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
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.
Request for Proposal
The request for proposal (RFP) is a formal request used by organizations to identify potential solutions and services from a list of vendors. Based on the RFP, the organization will identify a smaller list of vendors to issue a request for quotation. (Read: Five tips to a better Request for Proposal)
Request for Quotation
A request for quotation is a formal request for a vendor to provide actual costs for a specific service or scope of work. The client typically provides a vendor with a set of requirements and instructions on how to respond to the request. The vendor provides its response, including details about the solution, assumptions, and pricing.
Requirements
Requirements are descriptions of how a product or service should act, appear, or perform. Requirements generally refer to the features and functions of the deliverables you are building on your project. Requirements are considered to be a part of project scope. High-level scope is defined in your project definition (charter). The requirements form the detailed scope. After your requirements are approved, they can be changed through the scope change management process.
Resources
The people, equipment, purchases and other items needed to execute a project.
Retrospective
A team meeting that happens at the end of every development iteration to review lessons learned and to discuss how the team can be more efficient in the future. It is based on the principles of applying the learning from the previous sprint to the upcoming sprint.
Risk
There may be potential external events that will have a negative impact on your project if they occur. Risk refers to the combination of the probability the event will occur and the impact on the project if the event occurs. If the combination of the probability of the occurrence and the impact to the project is too high, you should identify the potential event as a risk and put a proactive plan in place to manage the risk.
Risk Management
A subset of project management that includes risk identification, risk quantification, risk response development and risk response control used to identify, analyze and respond to project risks.
Schedule
The project workplan tells you how you will complete the project. It describes the activities required, the sequence of the work, who is assigned to the work, an estimate of how much effort is required, when the work is due, and other information of interest to the project manager. The workplan allows the project manager to identify the work required to complete the project and also allows the project manager to monitor the work to determine whether the project is on schedule.
Schedule Variance
The schedule variance (SV) is an EV management term used to measure the project’s schedule performance by comparing the project’s EV to the project baselined planned value (PV). The formula is SV = EV – PV. A positive SV indicates the project is ahead of schedule, while a negative SV indicates the project is behind schedule.
Scope
Scope is the way you describe the boundaries of the project; it defines what the project will deliver and what it will not deliver. High-level scope is set in your project definition (charter) and includes all of your deliverables and the boundaries of your project. The detailed scope is identified through your business requirements. Any changes to your project deliverables, boundaries, or requirements would require approval through scope change management.
Scope Change Management
The purpose of scope change management is to manage change that occurs to previously approved scope statements and requirements. Scope is defined and approved in the scope section of the project definition (charter) and the more detailed business requirements. If the scope or the business requirements change during the project (and usually this means the client wants additional items), the estimates for cost, effort, and duration may no longer be valid. If the sponsor agrees to include the new work in the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort, and duration become the approved target. Sometimes the project manager thinks that scope management means having to tell the client “no.” That makes the project manager nervous and uncomfortable. However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope.
Scope Creep
The uncontrolled growth of the project scope resulting from constant changes to requirements without consideration to the impact on resources or timescale.
Scrum
Scrum is an iterative development methodology used to manage software projects. In scrum-based projects, there isn’t a specific project manager directing project team tasks; the team is self-directed, with co-located team members relying on communication over documentation for effective project delivery.
Scrum Master
Scrum is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks at hand. The role has also been referred to as servant-leader to reinforce these dual perspectives.
Scrum-ban
Scrum-ban is a mix between Scrum and Kanban, which supposedly contains the best features of both methods.
Self-Organization
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.
Six Sigma
Six Sigma is a management philosophy developed by Motorola that emphasizes setting extremely high objectives, collecting data, and analyzing results to a fine degree as a way to reduce defects in products and services.
Spike
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.
Sponsor
The person who has ultimate authority over the project. The executive sponsor provides project funding, resolves issues and scope changes, approves major deliverables, and provides high-level direction. He or she also champions the project within the organization. Depending on the project and the organizational level of the executive sponsor, he or she may delegate day-to-day tactical management to a project sponsor. If assigned, the project sponsor represents the executive sponsor on a day-to-day basis and makes most of the decisions requiring sponsor approval. If the decision is large enough, the project sponsor will take it to the executive sponsor.
Sprint
A fixed duration period of time where user stories are chosen to work on. The term Sprint comes from the Scrum methodology and is analogous to the term Iteration. A sprint is defined as a 2-4 week increment of software development activities that delivers working software and the end of the increment. External influences are not allowed to change the requirements of the stories being worked on.
Sprint Backlog
At the beginning of each sprint, the team has sprint planning with an end result being a backlog of work that the team anticipates completing at the end of the sprint. These are the items that the team will deliver against throughout the duration of the sprint.
Sprint Planning
Is a pre-sprint planning meeting attended by the core agile team. During the meeting the Product Owner describes the highest priority features to the team as described on the product backlog. The team then agrees on the number of features they can accomplish in the sprint and plans out the tasks required to achieve delivery of those features. The planning group works the features into User Stories and assigns Acceptance criteria to each story.
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.
Sprint Review
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.
Stakeholder
Specific people or groups who have a stake in the outcome of the project are stakeholders. Normally stakeholders are from within the company and may include internal clients, management, employees, administrators, etc. A project can also have external stakeholders, including suppliers, investors, community groups, and government organizations.
Standup Meeting
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.
Statement of Work (SOW)
The Statement of Work is the bible for the work the project must produce. The SOW is a key governance tool whether it is being used to direct work for a vendor or contractor, or used to direct the work internally, the SOW must contain a description of all the work that is expected.
Steering Committee
A steering committee is usually a group of high-level stakeholders who are responsible for providing guidance on overall strategic direction. They don’t take the place of a sponsor but help spread the strategic input and buy-in to a larger portion of the organization. The steering committee is especially valuable if your project has an impact in multiple organizations because it allows input from those organizations into decisions that affect them.
Story (User)
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.
Story Points
A story point is a relative estimation method used to determine the size of user stories so teams can determine how much work can be done during an iteration. Story points can be expressed in a simple Fibonacci sequence, t-shirt sizes, or a relative number. By adding up the number of user stories and associated story points, the project team can establish its velocity for future iteration planning.
Storyboard
A wall chart with cards and sticky notes that represents all the work for in a given sprint. The notes are moved across the board to show progress.
Student Syndrome
The type of procrastination students are prone to when facing a test or exam, typically leaving their revision until the last minute no matter how much time they had to prepare.
SWOT Analysis
A strategic planning tool used to evaluate the Strengths, Weaknesses, Opportunities, and Threats to a project. It involves specifying the objective of the project and identifying the internal and external factors that are favorable and unfavorable to achieving that objective.
Task
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.
Task Board
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.
TCO
Total Cost of Ownership (TCO) is an estimate of all direct and indirect costs associated with an asset or acquisition over its entire life.
Team
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.
Technical Debt
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.
Test Automation
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. 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 continuous integration and remain true to the commitment to not “break the build.”
Test Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development 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.
Theory of Constraints (TOC)
Theory of Constraints is a management philosophy of continuous improvement achieved by identifying and managing the most important constraint that affects quality and productivity.
Time-boxing
Time-boxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (time-boxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget.
Timebox
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.
Timeline
A graphic representation of the project components showing their dates and dependencies.
Unit Testing
A unit is the smallest testable part of a software system. In procedural programming, a unit may be an individual function or procedure. 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.
Use Case
The specification of tests that are conducted from the end-user perspective. Use cases focus on operating software as an end user would during their day-to-day activities.
User Persona
Personas are a description of the typical users of a given software. A persona description should include: 1) Skills and background – E.g. professional or beginner computer user. 2) Goals – E.g. what does the user expect from the product?
User Story
A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. A user story is also a placeholder for conversation between the users and the team. The user stories should be written by or for the customers for a software project and are their main instrument to influence the development of the software. User stories could also be written by developers to express non-functional requirements (security, performance, quality, etc.)
Vanity Metric
A metric that is not actionable, and exists to make us feel better or show off. Suspect any matric that graphs always up and to the right is probably a vanity metric.
Velocity
It is a relative number which describes how much work the team can get done over a period of time.
Vertical Slice
Showing off a feature in an application that works from start to finish but may be limited in scope. For example a rope bridge crossing a chasm is immediately useful and allows people to cross. Having that in place can help to build a better bridge later.
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.
Waterfall Methodology
A waterfall methodology is a predictive life cycle methodology with sequential phases, which include Analysis, Design, Development, Testing, and Deployment. Predictive methodologies work well when the requirements and design are well defined, as found in the construction or manufacturing processes. For software projects, an agile methodology is recommended despite the abundance of waterfall methodologies found across industries.
Waterfall Model
A sequential development process, in which development flows steadily downwards (like a waterfall) through the phases of initiation, analysis, design, build, test and maintenance. To follow the waterfall model, you move from one phase to the next sequentially, with no overlapping or iterative steps.
Wiki
An editable intranet site where details of stories and tracking information may be recorded during development.
WIP
Also known as Work in Progress is any work that has been started but has yet to be completed.
Work Breakdown Structure
The work breakdown structure (WBS) is a list of major deliverables that the project team will complete during the project. The WBS is organized in a hierarchy and is typically decomposed into several sub-levels. A WBS can be used to visually define the project into smaller chunks, so the team can better understand and plan the activities needed to complete the deliverables. Diagramming tools such as Microsoft Visio or mind mapping tools such asMindjet or MindGenius can be used to build a visual WBS. (Read: Five tips for building a work breakdown structure)
Work in Progress (WIP)
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.
Work Schedule
The project schedule is commonly associated with Microsoft Project or a similar scheduling tool. The project schedule is the series of tasks with durations, resources, and specific dependencies that forecasts the project end date.
Workplan
The project workplan tells you how you will complete the project. It describes the activities required, the sequence of the work, who is assigned to the work, an estimate of how much effort is required, when the work is due, and other information of interest to the project manager. The workplan allows the project manager to identify the work required to complete the project and also allows the project manager to monitor the work to determine whether the project is on schedule.
XP
A software development methodology which 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 (time-boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
