Actions

Difference between revisions of "Agile Project Management"

m
m
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
'''Sales pipeline management''' is the management practice of defining, monitoring, advancing, and improving sales opportunities as they move through the stages of an organization's selling process. It combines opportunity qualification, stage criteria, assignment of responsibility, customer engagement, pipeline reviews, data governance, and performance analysis to help sales teams focus their effort and make better commercial decisions.
+
'''Agile project management''' is an adaptive approach to directing and delivering projects through iterative planning, frequent feedback, incremental delivery, and continuing adjustment as requirements and circumstances change. It applies agile values and principles to project objectives, scope, priorities, collaboration, risk, and performance while preserving accountability for resources and outcomes. Instead of assuming that all requirements and solutions can be specified accurately at the outset, agile project management uses evidence from completed work and stakeholder feedback to inform subsequent decisions.
  
−
A '''sales pipeline''' represents the current set of potential deals and their progress toward an agreed outcome, usually a sale. '''Sales pipeline management''' is the continuing discipline that maintains the accuracy of that representation and guides what happens next. It is supported by [[Customer Relationship Management (CRM)]] systems and forms part of [[Sales Management]] and [[Sales Operations]].
+
The approach is especially useful when the desired outcome is clear but the detailed solution, user needs, or technical conditions are uncertain. It is used in software development, digital products, business transformation, and other knowledge-intensive work. Its applicability depends on the project's constraints, dependencies, regulatory obligations, and ability to deliver and evaluate useful increments.
  
−
Sales pipeline management is related to [[Sales Forecasting]], but they answer different questions. Pipeline management examines which opportunities exist, how credible they are, what obstructs progress, and what actions might help. Forecasting estimates what business is likely to close within a specified period. A large pipeline therefore does not necessarily imply a strong revenue forecast.<ref name="salesforce-guide">Salesforce (2026), ''Sales Pipeline Management: A Complete Guide and the Best Tools in 2026'', [https://www.salesforce.com/sales/pipeline/management/ official guide], 6 April.</ref>
+
Agile project management is broader than [[SCRUM]], [[Kanban]], or any single delivery method. It remains a form of [[Project Management]] and may coexist with predictive planning, formal funding approvals, contracts, architecture controls, and enterprise governance. The [[Project Management Institute (PMI)]] recognizes predictive, agile, and hybrid approaches as options to be selected and tailored to the context.<ref name="pmi-guide">Project Management Institute (2026), ''Agile Practice Guide'', second edition, July, [https://www.pmi.org/standards/agile official guide].</ref>
  
−
== Purpose and scope ==
+
== Origins and underlying principles ==
  
−
Sales pipeline management provides visibility into the flow of qualified opportunities and the resources needed to convert them into customers. It helps managers distinguish a promising deal from an unverified prospect, identify stalled opportunities, and allocate attention according to business value and the buyer's actual progress.
+
Modern agile practice draws heavily on the ''Manifesto for Agile Software Development'', published in 2001. The manifesto emphasizes people and collaboration, working solutions, customer involvement, and responsiveness to change. Its twelve supporting principles include frequent delivery, sustainable work, technical excellence, and regular reflection.<ref name="manifesto">Beck, K. et al. (2001), ''Manifesto for Agile Software Development'', [https://agilemanifesto.org/ official text]; ''Principles behind the Agile Manifesto'', [https://agilemanifesto.org/principles official principles].</ref>
  
−
Its principal objectives are to:
+
The manifesto originated in software development, but agile approaches have subsequently been adapted to project, product, portfolio, and organizational settings. Agile does not mean planning is unnecessary or that commitments are irrelevant. Rather, planning and control are continually informed by validated knowledge instead of depending exclusively on an initial plan.
−
* Maintain a consistent and current view of sales opportunities.
 
−
* Define observable requirements for progressing between sales stages.
 
−
* Improve qualification and decisions about which deals to pursue.
 
−
* Identify bottlenecks, delays, and gaps in customer engagement.
 
−
* Support coaching, resource allocation, and opportunity decisions.
 
−
* Provide credible data for sales forecasting and business planning.
 
−
* Learn from won, lost, and abandoned opportunities to improve the selling process.
 
  
−
Its scope varies by sales model. A short retail or self-service transaction may use a relatively simple pipeline, while complex enterprise sales may require multiple stakeholders, procurement stages, security reviews, proofs of concept, and negotiation milestones.
+
The term ''agile project management'' describes the application of those ideas to a bounded project. Long-lived product management can use similar practices without treating every release or increment as a separate project.
  
−
== Typical sales pipeline stages ==
+
== How agile project management works ==
  
−
A pipeline's stages reflect an organization's actual selling process. There is no universal number or exact sequence of stages. Salesforce's guidance describes qualification, meetings, proposals, negotiation, and closing as common steps, while emphasizing measurable stage-entry and exit criteria.<ref name="stages">Salesforce, ''What Are the Stages of a Sales Pipeline?'', [https://www.salesforce.com/sales/pipeline/stages/ official guide], accessed 28 October 2026.</ref>
+
Agile projects commonly organize work into manageable increments, use regular stakeholder feedback, make priorities visible, and adapt future work based on outcomes. The exact cadence, team structure, and artifacts depend on the chosen method.
 +
 
 +
=== Establish objectives and boundaries ===
 +
 
 +
Sponsors and delivery teams begin with the problem to be addressed, intended beneficiaries, expected value, constraints, available resources, and major risks. A project may have an approved business case, target date, funding limit, and non-negotiable compliance requirements even while some features remain undecided.
 +
 
 +
A useful project objective states the intended outcome rather than prescribing every implementation detail. For example, improving a digital service's completion rate provides a testable direction while permitting several possible design solutions.
 +
 
 +
=== Organize and prioritize work ===
 +
 
 +
Desired capabilities and changes are captured in a prioritized collection of work, frequently called a backlog. Items may be described as user needs, features, defects, experiments, or technical tasks. Prioritization considers business value, urgency, dependencies, risk, learning value, and available capacity.
 +
 
 +
Work items should be sufficiently clear for the next delivery interval. Detailed planning can occur closer to implementation, when more information is available. Unclear or oversized items may be refined or decomposed before work begins.
 +
 
 +
=== Deliver increments and obtain feedback ===
 +
 
 +
Teams produce usable or testable outputs in short cycles or through continuous flow. Stakeholders inspect results, evaluate whether assumptions are holding, and identify changes in requirements or priorities. Feedback can come from users, testing, operational telemetry, demonstrations, or business results.
 +
 
 +
Incremental delivery does not always mean that an increment can be released immediately into production. Safety, regulatory, contractual, integration, or change-management controls may require coordinated deployment and additional verification.
 +
 
 +
=== Inspect, adapt, and coordinate ===
 +
 
 +
Delivery teams periodically review progress, obstacles, quality, and their ways of working. Project-level oversight considers the emerging completion forecast, cost, dependencies, unresolved risks, and whether the project still justifies continued investment.
 +
 
 +
Adaptation may involve reordering work, simplifying scope, revising estimates, seeking approval for a material change, or terminating an initiative whose expected value is no longer credible.
 +
 
 +
== Agile delivery approaches ==
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! Illustrative stage
+
! Approach
−
! Main decision
+
! Characteristic mechanism
−
! Evidence of progress
+
! Suitable context or consideration
−
|-
 
−
| Prospecting and initial contact
 
−
| Does a potential customer fit the intended market?
 
−
| Identified account, contact, and plausible need
 
 
|-
 
|-
−
| Qualification
+
| Scrum
−
| Is there a credible opportunity worth pursuing?
+
| Timeboxed Sprints, defined accountabilities, events, and artifacts
−
| Confirmed need, buyer context, timing, and relevant qualification evidence
+
| Complex work benefiting from frequent inspection and adaptation
 
|-
 
|-
−
| Discovery and solution assessment
+
| Kanban
−
| Can the proposed offering address the customer's requirements?
+
| Visualized workflow, explicit policies, limited work in progress, and flow improvement
−
| Customer-validated requirements and solution fit
+
| Continuous work with varying arrival rates and delivery needs
 
|-
 
|-
−
| Proposal
+
| Extreme Programming (XP)
−
| Is there a defined commercial offer for customer review?
+
| Engineering practices including automated testing, integration, and collaborative development
−
| Scope, offer, pricing assumptions, and proposal delivered to appropriate stakeholders
+
| Software work requiring high technical quality and responsiveness
 
|-
 
|-
−
| Negotiation and approval
+
| Lean-oriented approaches
−
| Can both parties reach an acceptable commercial commitment?
+
| Attention to customer value, flow, waste, and systemic improvement
−
| Progress on terms, approvals, procurement, and outstanding conditions
+
| Improving delivery systems and resource use
 
|-
 
|-
−
| Closed won or closed lost
+
| Hybrid approaches
−
| What was the final commercial outcome?
+
| Deliberate combination of predictive and adaptive practices
−
| Executed agreement or documented loss or withdrawal
+
| Projects with both uncertain solution elements and fixed external constraints
 
|}
 
|}
  
−
Post-sale onboarding and expansion are important downstream activities but may belong to separate [[Account Management]] or [[Customer Success Management]] pipelines. They should not be assumed to be part of every acquisition pipeline.
+
These approaches are not mutually exclusive. A Scrum team may use Kanban visualization and XP engineering practices. A project can combine iterative product development with formal procurement milestones or regulated deployment approvals.
  
−
Stage movement should rely on evidence rather than seller optimism. For example, sending a proposal does not establish that a customer has accepted its terms. Organizations should define how opportunities are paused, requalified, disqualified, reopened, and transferred between owners.
+
=== Scrum as one example ===
  
−
== How sales pipeline management works ==
+
The ''Scrum Guide'', authored by Ken Schwaber and Jeff Sutherland, defines Scrum as a lightweight framework for addressing complex problems. It specifies the accountabilities of Product Owner, Scrum Master, and Developers; events including the Sprint, planning, Daily Scrum, review, and retrospective; and artifacts with associated commitments.<ref name="scrum">Schwaber, K. and Sutherland, J. (2020), ''The Scrum Guide'', November, [https://scrumguides.org/scrum-guide.html official guide].</ref>
  
−
=== Define the opportunity and its ownership ===
+
These are Scrum-specific features. Other agile approaches do not necessarily use Sprints, story points, a Scrum Master, or the same artifacts. A project manager may coordinate broader budgets, suppliers, and organizational dependencies without replacing the accountabilities defined within a Scrum Team.
  
−
The sales organization establishes what qualifies as an opportunity, which accounts can have more than one open opportunity, and when responsibility transfers among prospecting, sales, partners, and account teams. Opportunity identity rules help prevent duplicates and inflated pipeline totals.
+
== Planning and governance ==
  
−
=== Establish qualification and stage criteria ===
+
Adaptive delivery requires appropriate governance even when the detailed scope evolves. Executive oversight should distinguish decisions delegated to the delivery team from those requiring sponsor, portfolio, security, architecture, or financial authorization.
  
−
Qualification tests whether customer demand is real, the offering is suitable, and a sale is plausible. Evidence may concern customer need, decision process, ability to fund, purchasing timeline, stakeholders, competition, and technical feasibility. A particular qualification method can help, but rigid scoring should not substitute for a documented understanding of the opportunity.
+
{| class="wikitable"
 +
! Management concern
 +
! Agile project practice
 +
! Governance implication
 +
|-
 +
| Scope
 +
| Progressive elaboration and priority-based sequencing
 +
| Protect required outcomes and formally handle material commitment changes
 +
|-
 +
| Schedule
 +
| Short-term delivery planning and regularly updated forecasts
 +
| Monitor external deadlines, dependencies, and credible completion ranges
 +
|-
 +
| Cost
 +
| Capacity-based funding and tracking of actual expenditure
 +
| Retain funding authority, cost transparency, and exception controls
 +
|-
 +
| Quality
 +
| Continuous testing, review, and explicit acceptance criteria
 +
| Maintain independent assurance where risk or regulation requires it
 +
|-
 +
| Risk
 +
| Early experiments, incremental validation, and visible impediments
 +
| Escalate systemic, security, legal, and enterprise-level exposures
 +
|-
 +
| Benefits
 +
| Frequent checks of user and business outcomes
 +
| Connect delivered outputs to [[Benefits realization management|benefits realization]]
 +
|}
  
−
=== Maintain opportunity records ===
+
A project can retain a business case and decision gates while allowing its delivery plan to evolve. Agile governance is ineffective when local flexibility is confused with unlimited authority to change contractual obligations, risk tolerances, or funding.
  
−
CRM records commonly contain an account, owner, estimated value, stage, expected closing date, key contacts, next action, dependencies, and deal-specific risks. Required fields should be proportionate to the decisions they support. Mandatory fields filled with guesses create an appearance of data quality rather than real reliability.
+
== Roles and responsibilities ==
  
−
=== Conduct pipeline reviews ===
+
Project sponsors establish objectives, funding boundaries, and strategic accountability. Business and product representatives clarify user needs and assess outcomes. Delivery teams design, build, test, and integrate working solutions. Project managers or delivery leads coordinate project-level obligations, dependencies, stakeholders, risks, and reporting when those responsibilities exist in the operating model.
  
−
Pipeline reviews examine changes in deal status, stage aging, upcoming customer decisions, blocked activities, and the credibility of the recorded opportunity. Reviews should produce actions or decisions, such as arranging a stakeholder meeting, resolving a technical concern, revising a proposal, or disqualifying an unviable deal.
+
Other functions may include [[Project Management Office (PMO)|project management offices]], [[Enterprise Architecture|enterprise architects]], cybersecurity, operations, procurement, compliance, and financial management. Their participation should be proportionate to the work and integrated into delivery rather than treated as an unrelated sequence of late approvals.
  
−
Salesforce recommends regular pipeline review and analysis of stage conversion and stalled opportunities.<ref name="salesforce-guide" /> The review frequency should reflect the sales cycle, deal complexity, and changing business conditions.
+
Responsibility is determined by organizational design and selected framework. There is no universal rule that every agile project must employ a traditional project manager, or that adopting Scrum eliminates all project-management work.
  
−
=== Reconcile pipeline data with forecasting ===
+
== Common artifacts and information ==
  
−
Opportunity value and stage are inputs into sales forecasts, not forecasts by themselves. Forecasting may incorporate historical win rates, customer commitments, deal timing, sales judgment, and other evidence. Salesforce's forecasting documentation distinguishes pipeline, best case, commit, and closed categories, although actual configurations depend on the organization.<ref name="forecast">Salesforce Help, ''Set Up Pipeline Forecasting'', [https://help.salesforce.com/s/articleView?id=sf.forecasts3_setup_intro.htm&amp;language=en_US&amp;type=5 official documentation], accessed 28 October 2026.</ref>
+
Typical agile project information includes a concise project objective or charter, prioritized backlog, release or delivery forecast, acceptance criteria, risk and dependency records, test evidence, and measures of value and delivery performance. Teams may also maintain architectural decisions, change records, stakeholder communication plans, and operational readiness criteria.
  
−
=== Improve the selling process ===
+
The quantity of documentation should reflect its decision and assurance value. Minimizing paperwork does not justify losing critical evidence for security, regulatory compliance, customer obligations, or service continuity.
  
−
Managers use patterns in wins, losses, stage delays, and customer objections to review qualification rules, messaging, capacity, pricing, approvals, and sales skills. A consistently low conversion rate at a particular stage can indicate a process weakness, unsuitable opportunities, or a mismatch between the offer and customer requirements.
+
== Measuring performance ==
  
−
== Pipeline performance measures ==
+
Agile project management uses a combination of delivery, quality, financial, and outcome measures. No single activity measure establishes whether the project is successful.
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! Measure
 
! Measure
−
! What it indicates
+
! Interpretation
−
! Interpretation caution
+
! Limitation
−
|-
 
−
| Open pipeline value
 
−
| Total estimated value of qualifying open opportunities
 
−
| Potential contract value is not realized revenue
 
 
|-
 
|-
−
| Stage conversion rate
+
| Lead time or cycle time
−
| Share of eligible opportunities moving from one defined stage to another
+
| Time required for work to pass through defined stages
−
| Requires comparable cohorts and stage definitions
+
| Requires stable start, finish, and item definitions
 
|-
 
|-
−
| Win rate
+
| Throughput
−
| Share of decided opportunities won under a specified denominator
+
| Number of qualifying work items completed in a period
−
| Results change depending on whether only won and lost deals or all qualified entries are included
+
| Items differ in size, complexity, and value
 
|-
 
|-
−
| Sales cycle length
+
| Work in progress
−
| Time from a defined starting milestone to a closing event
+
| Work actively underway at a point in time
−
| Open and censored opportunities need consistent treatment
+
| Low values do not automatically establish healthy flow
 
|-
 
|-
−
| Stage aging
+
| Delivery predictability
−
| Time opportunities have remained in a stage
+
| Relationship between forecast and achieved work or dates
−
| Long duration can reflect deal complexity rather than a management defect
+
| Forecast changes and scope changes must be visible
 
|-
 
|-
−
| Pipeline coverage
+
| Escaped defects
−
| Eligible pipeline value divided by the corresponding sales target
+
| Problems discovered after the agreed quality checkpoint or release
−
| Required coverage depends on win rates, timing, and deal mix
+
| Depends on detection and reporting practices
 
|-
 
|-
−
| Pipeline velocity
+
| Customer or user outcomes
−
| Rate at which opportunities generate value under a specified formula
+
| Improvement in adoption, task success, experience, or other desired effects
−
| Simplified formulas assume stable populations and can conceal uncertainty
+
| Causal attribution and measurement windows need care
 
|-
 
|-
−
| Forecast accuracy
+
| Budget and forecast variance
−
| Difference between a frozen forecast and the later comparable result
+
| Financial difference between approved resources and anticipated or actual cost
−
| Forecast snapshots and consistent financial definitions are essential
+
| Delivery efficiency does not prove commercial value
−
|-
 
−
| Data freshness
 
−
| Currency of key opportunity fields and next actions
 
−
| Recent updates do not necessarily mean the information is accurate
 
 
|}
 
|}
  
−
Pipeline velocity is sometimes estimated as: number of opportunities multiplied by average deal value and win rate, divided by average sales cycle length. This is a diagnostic approximation, not an accounting measure or a guaranteed future-revenue calculation. The time units, populations, and win-rate definitions must be aligned.
+
Velocity and story points may support planning inside a team that chooses to use them, but they are not standardized units of business value or suitable universal comparisons between teams. PMI's second edition of the ''Agile Practice Guide'' places greater emphasis on flow, outcomes, value, and context-sensitive measurement.<ref name="pmi-metrics">Project Management Institute (2026), ''What's New in the Agile Practice Guide – Second Edition'', 2 September, [https://www.pmi.org/blog/agile-practice-guide-second-edition PMI article].</ref>
  
−
A pipeline can have high aggregate value but poor quality when deals are duplicated, stage criteria are weak, or closing dates are repeatedly postponed. Conversely, a smaller pipeline with well-qualified opportunities and credible next steps may support better decisions.
+
== When agile project management is appropriate ==
  
−
== Governance and responsibilities ==
+
Agile approaches are particularly relevant when user needs can be investigated through feedback, requirements are expected to evolve, the work can be divided into meaningful increments, and the organization can support frequent decisions.
  
−
'''Sales managers''' lead opportunity reviews, coach sellers, challenge assumptions, and decide where the team should invest effort. '''Sales representatives''' maintain evidence-based opportunity records, customer engagement, and next actions. '''Sales operations''' defines stages, reporting rules, CRM data standards, and pipeline analytics. '''Revenue operations''' may coordinate shared lifecycle definitions across marketing, sales, and post-sale teams.
+
They can be harder to apply where a solution is fully specified and repeatable, dependencies prevent meaningful incremental validation, contractual commitments rigidly fix scope and sequence, or the costs of frequent changes are unusually high. Such constraints do not automatically rule out all agile techniques; they change the appropriate mix.
  
−
'''Marketing''' contributes qualified demand and feedback on lead quality. '''Finance''' reconciles booking and revenue concepts with planning and forecasting. '''Product, technical, legal, and commercial specialists''' support feasibility, security, pricing, and contracting where complex deals require additional review.
+
A hybrid arrangement may preserve a predictive infrastructure installation plan while using iterative design and validation for a new application. Selection should be based on the actual uncertainty and delivery system, rather than labeling a method universally superior.
  
−
Decision rights should cover opportunity ownership, material value changes, closing-date changes, reclassification, exceptions, and approval for nonstandard commercial terms. Review governance must not reward artificial pipeline growth or discourage honest disqualification.
+
== Common challenges and failure modes ==
  
−
== Technology and automation ==
+
'''Agile treated as the absence of planning.''' Teams may begin work without a shared objective, realistic capacity, or an explicit basis for prioritization.
  
−
CRM platforms commonly provide pipeline boards, stage histories, tasks, forecasting views, dashboards, and integrations with email, marketing, quoting, and contract systems. Automation can route new inquiries, remind owners about aging deals, detect incomplete records, or flag conflicting data.
+
'''Ceremonies without adaptation.''' Regular meetings and iterations produce limited value when findings do not alter decisions, design, or delivery practices.
  
−
AI-assisted tools may suggest opportunity scores, summarize deal histories, or identify patterns associated with past outcomes. These suggestions depend on data quality and can embed historical bias or confuse correlation with customer commitment. Human review remains important for consequential changes to deal value, forecast categories, customer communications, and commercial promises.
+
'''Output substituted for outcome.''' Large numbers of completed tasks or features may coexist with poor user adoption and little measurable business improvement.
  
−
== Common challenges ==
+
'''Unmanaged dependencies.''' Teams may optimize their own throughput while shared platforms, suppliers, and approval processes constrain end-to-end delivery.
  
−
'''Inflated pipeline.''' Duplicate opportunities, speculative deal amounts, and weak qualification can create misleading totals.
+
'''Weak engineering discipline.''' Frequent delivery can increase defects and operational risk without automated testing, integration practices, secure design, and quality controls.
  
−
'''Stage ambiguity.''' Sellers may interpret the same stage differently, making comparisons unreliable.
+
'''Unclear decision rights.''' Conflicts arise when sponsors, product owners, project managers, and technical leaders have overlapping or contradictory authority.
  
−
'''Stale opportunities.''' Deals remain open with outdated closing dates or no verified next customer action.
+
'''Forced use across unsuitable work.''' A single method applied without tailoring can create avoidable overhead or weaken accountability.
−
 
 
−
'''Forecast pressure.''' Targets may encourage optimistic classifications rather than evidence-based reporting.
 
−
 
 
−
'''Overadministration.''' Excessive CRM requirements consume selling time without improving decisions.
 
−
 
 
−
'''Fragmented customer context.''' Sales, marketing, partners, and customer teams maintain conflicting records or unclear ownership.
 
−
 
 
−
'''Misreading metrics.''' Aggregate win rates and velocity figures conceal differences by segment, deal size, sales motion, or period.
 
  
 
== Illustrative example ==
 
== Illustrative example ==
  
−
Consider a hypothetical enterprise software company whose pipeline appears sufficient to meet its quarterly bookings target. During review, managers discover that several large opportunities have not completed required security assessments, while others have closing dates that sellers repeatedly moved forward.
+
Consider a hypothetical public-service organization replacing a complicated online application process. The project has an approved budget, security requirements, and a fixed date for a regulatory change. Rather than designing every screen in advance, the team tests short increments with representative users and measures completion rates, accessibility issues, and processing errors.
  
−
Sales operations separates evidence-verified opportunities from speculative ones and clarifies stage criteria. Sales managers work with sellers to identify actual buyer decisions, technical dependencies, and next actions. Finance uses a revised forecast based on the improved records. The pipeline may become smaller on paper, but managers gain a more reliable view of commercial exposure and work required.
+
The project sponsor retains funding and policy decisions, while the product team adjusts the backlog based on evidence. Architecture and security reviews occur throughout development; deployment remains subject to required controls. If testing shows that a proposed feature adds complexity without improving the service, the team may remove it from the next delivery increment. The example illustrates how adaptive planning and formal governance can work together.
  
−
The example illustrates why pipeline management is concerned with opportunity quality and progression rather than maximizing the apparent value of open deals.
+
== Relationship to adjacent disciplines ==
−
 
 
−
== Relationship to related disciplines ==
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! Discipline
 
! Discipline
 
! Primary focus
 
! Primary focus
−
! Relationship to pipeline management
+
! Relationship to agile project management
 
|-
 
|-
−
| Sales management
+
| Project management
−
| Leading salespeople and achieving commercial results
+
| Governing temporary work to achieve defined objectives
−
| Owns opportunity decisions and uses pipeline reviews to guide action
+
| Parent discipline embracing predictive, adaptive, and hybrid delivery
 
|-
 
|-
−
| Sales operations
+
| Scrum
−
| Designing sales processes, data, systems, and reporting
+
| A specific framework for complex work
−
| Establishes pipeline controls and provides operational infrastructure
+
| One possible framework used within agile project delivery
 
|-
 
|-
−
| Sales forecasting
+
| Product management
−
| Estimating future bookings or revenue over a defined period
+
| Long-term value, evolution, and success of a product
−
| Consumes qualified pipeline evidence and other predictive inputs
+
| Can supply priorities and outcome direction across multiple projects
 
|-
 
|-
−
| Revenue operations
+
| DevOps
−
| Coordinating revenue-related processes across the customer lifecycle
+
| Collaboration and technical practices for building, releasing, and operating systems
−
| Aligns pipeline definitions and handoffs across functions
+
| Can enable rapid and reliable incremental delivery
 
|-
 
|-
−
| Sales funnel management
+
| Portfolio management
−
| Analyzing progression and conversion across buyer or lead populations
+
| Selecting and governing a collection of investments and initiatives
−
| Complements the opportunity-level view of the sales pipeline
+
| Allocates funding and priorities across agile and non-agile work
 
|-
 
|-
−
| Account management
+
| Change management
−
| Managing existing customer relationships and commercial growth
+
| Governing or enabling organizational and technical changes, depending on context
−
| May own renewal and expansion opportunities in separate pipelines
+
| Supports safe deployment and adoption of delivered capabilities
 
|}
 
|}
  
 
== See also ==
 
== See also ==
−
* [[Sales Management]]
+
 
−
* [[Sales Operations]]
+
* [[Project Management]]
−
* [[Sales Forecasting]]
+
* [[SCRUM]]
−
* [[Revenue Operations]]
+
* [[Kanban]]
−
* [[Customer Relationship Management (CRM)]]
+
* [[Agile Software Development]]
−
* [[Sales Funnel]]
+
* [[Product Management]]
−
* [[Lead Management]]
+
* [[Project Management Institute (PMI)]]
−
* [[Account Management]]
+
* [[DevOps]]
 +
* [[Benefits realization management]]
  
 
== References ==
 
== References ==
 +
 
<references />
 
<references />

Latest revision as of 16:15, 28 October 2026

Agile project management is an adaptive approach to directing and delivering projects through iterative planning, frequent feedback, incremental delivery, and continuing adjustment as requirements and circumstances change. It applies agile values and principles to project objectives, scope, priorities, collaboration, risk, and performance while preserving accountability for resources and outcomes. Instead of assuming that all requirements and solutions can be specified accurately at the outset, agile project management uses evidence from completed work and stakeholder feedback to inform subsequent decisions.

The approach is especially useful when the desired outcome is clear but the detailed solution, user needs, or technical conditions are uncertain. It is used in software development, digital products, business transformation, and other knowledge-intensive work. Its applicability depends on the project's constraints, dependencies, regulatory obligations, and ability to deliver and evaluate useful increments.

Agile project management is broader than SCRUM, Kanban, or any single delivery method. It remains a form of Project Management and may coexist with predictive planning, formal funding approvals, contracts, architecture controls, and enterprise governance. The Project Management Institute (PMI) recognizes predictive, agile, and hybrid approaches as options to be selected and tailored to the context.[1]

Origins and underlying principles

Modern agile practice draws heavily on the Manifesto for Agile Software Development, published in 2001. The manifesto emphasizes people and collaboration, working solutions, customer involvement, and responsiveness to change. Its twelve supporting principles include frequent delivery, sustainable work, technical excellence, and regular reflection.[2]

The manifesto originated in software development, but agile approaches have subsequently been adapted to project, product, portfolio, and organizational settings. Agile does not mean planning is unnecessary or that commitments are irrelevant. Rather, planning and control are continually informed by validated knowledge instead of depending exclusively on an initial plan.

The term agile project management describes the application of those ideas to a bounded project. Long-lived product management can use similar practices without treating every release or increment as a separate project.

How agile project management works

Agile projects commonly organize work into manageable increments, use regular stakeholder feedback, make priorities visible, and adapt future work based on outcomes. The exact cadence, team structure, and artifacts depend on the chosen method.

Establish objectives and boundaries

Sponsors and delivery teams begin with the problem to be addressed, intended beneficiaries, expected value, constraints, available resources, and major risks. A project may have an approved business case, target date, funding limit, and non-negotiable compliance requirements even while some features remain undecided.

A useful project objective states the intended outcome rather than prescribing every implementation detail. For example, improving a digital service's completion rate provides a testable direction while permitting several possible design solutions.

Organize and prioritize work

Desired capabilities and changes are captured in a prioritized collection of work, frequently called a backlog. Items may be described as user needs, features, defects, experiments, or technical tasks. Prioritization considers business value, urgency, dependencies, risk, learning value, and available capacity.

Work items should be sufficiently clear for the next delivery interval. Detailed planning can occur closer to implementation, when more information is available. Unclear or oversized items may be refined or decomposed before work begins.

Deliver increments and obtain feedback

Teams produce usable or testable outputs in short cycles or through continuous flow. Stakeholders inspect results, evaluate whether assumptions are holding, and identify changes in requirements or priorities. Feedback can come from users, testing, operational telemetry, demonstrations, or business results.

Incremental delivery does not always mean that an increment can be released immediately into production. Safety, regulatory, contractual, integration, or change-management controls may require coordinated deployment and additional verification.

Inspect, adapt, and coordinate

Delivery teams periodically review progress, obstacles, quality, and their ways of working. Project-level oversight considers the emerging completion forecast, cost, dependencies, unresolved risks, and whether the project still justifies continued investment.

Adaptation may involve reordering work, simplifying scope, revising estimates, seeking approval for a material change, or terminating an initiative whose expected value is no longer credible.

Agile delivery approaches

Approach Characteristic mechanism Suitable context or consideration
Scrum Timeboxed Sprints, defined accountabilities, events, and artifacts Complex work benefiting from frequent inspection and adaptation
Kanban Visualized workflow, explicit policies, limited work in progress, and flow improvement Continuous work with varying arrival rates and delivery needs
Extreme Programming (XP) Engineering practices including automated testing, integration, and collaborative development Software work requiring high technical quality and responsiveness
Lean-oriented approaches Attention to customer value, flow, waste, and systemic improvement Improving delivery systems and resource use
Hybrid approaches Deliberate combination of predictive and adaptive practices Projects with both uncertain solution elements and fixed external constraints

These approaches are not mutually exclusive. A Scrum team may use Kanban visualization and XP engineering practices. A project can combine iterative product development with formal procurement milestones or regulated deployment approvals.

Scrum as one example

The Scrum Guide, authored by Ken Schwaber and Jeff Sutherland, defines Scrum as a lightweight framework for addressing complex problems. It specifies the accountabilities of Product Owner, Scrum Master, and Developers; events including the Sprint, planning, Daily Scrum, review, and retrospective; and artifacts with associated commitments.[3]

These are Scrum-specific features. Other agile approaches do not necessarily use Sprints, story points, a Scrum Master, or the same artifacts. A project manager may coordinate broader budgets, suppliers, and organizational dependencies without replacing the accountabilities defined within a Scrum Team.

Planning and governance

Adaptive delivery requires appropriate governance even when the detailed scope evolves. Executive oversight should distinguish decisions delegated to the delivery team from those requiring sponsor, portfolio, security, architecture, or financial authorization.

Management concern Agile project practice Governance implication
Scope Progressive elaboration and priority-based sequencing Protect required outcomes and formally handle material commitment changes
Schedule Short-term delivery planning and regularly updated forecasts Monitor external deadlines, dependencies, and credible completion ranges
Cost Capacity-based funding and tracking of actual expenditure Retain funding authority, cost transparency, and exception controls
Quality Continuous testing, review, and explicit acceptance criteria Maintain independent assurance where risk or regulation requires it
Risk Early experiments, incremental validation, and visible impediments Escalate systemic, security, legal, and enterprise-level exposures
Benefits Frequent checks of user and business outcomes Connect delivered outputs to benefits realization

A project can retain a business case and decision gates while allowing its delivery plan to evolve. Agile governance is ineffective when local flexibility is confused with unlimited authority to change contractual obligations, risk tolerances, or funding.

Roles and responsibilities

Project sponsors establish objectives, funding boundaries, and strategic accountability. Business and product representatives clarify user needs and assess outcomes. Delivery teams design, build, test, and integrate working solutions. Project managers or delivery leads coordinate project-level obligations, dependencies, stakeholders, risks, and reporting when those responsibilities exist in the operating model.

Other functions may include project management offices, enterprise architects, cybersecurity, operations, procurement, compliance, and financial management. Their participation should be proportionate to the work and integrated into delivery rather than treated as an unrelated sequence of late approvals.

Responsibility is determined by organizational design and selected framework. There is no universal rule that every agile project must employ a traditional project manager, or that adopting Scrum eliminates all project-management work.

Common artifacts and information

Typical agile project information includes a concise project objective or charter, prioritized backlog, release or delivery forecast, acceptance criteria, risk and dependency records, test evidence, and measures of value and delivery performance. Teams may also maintain architectural decisions, change records, stakeholder communication plans, and operational readiness criteria.

The quantity of documentation should reflect its decision and assurance value. Minimizing paperwork does not justify losing critical evidence for security, regulatory compliance, customer obligations, or service continuity.

Measuring performance

Agile project management uses a combination of delivery, quality, financial, and outcome measures. No single activity measure establishes whether the project is successful.

Measure Interpretation Limitation
Lead time or cycle time Time required for work to pass through defined stages Requires stable start, finish, and item definitions
Throughput Number of qualifying work items completed in a period Items differ in size, complexity, and value
Work in progress Work actively underway at a point in time Low values do not automatically establish healthy flow
Delivery predictability Relationship between forecast and achieved work or dates Forecast changes and scope changes must be visible
Escaped defects Problems discovered after the agreed quality checkpoint or release Depends on detection and reporting practices
Customer or user outcomes Improvement in adoption, task success, experience, or other desired effects Causal attribution and measurement windows need care
Budget and forecast variance Financial difference between approved resources and anticipated or actual cost Delivery efficiency does not prove commercial value

Velocity and story points may support planning inside a team that chooses to use them, but they are not standardized units of business value or suitable universal comparisons between teams. PMI's second edition of the Agile Practice Guide places greater emphasis on flow, outcomes, value, and context-sensitive measurement.[4]

When agile project management is appropriate

Agile approaches are particularly relevant when user needs can be investigated through feedback, requirements are expected to evolve, the work can be divided into meaningful increments, and the organization can support frequent decisions.

They can be harder to apply where a solution is fully specified and repeatable, dependencies prevent meaningful incremental validation, contractual commitments rigidly fix scope and sequence, or the costs of frequent changes are unusually high. Such constraints do not automatically rule out all agile techniques; they change the appropriate mix.

A hybrid arrangement may preserve a predictive infrastructure installation plan while using iterative design and validation for a new application. Selection should be based on the actual uncertainty and delivery system, rather than labeling a method universally superior.

Common challenges and failure modes

Agile treated as the absence of planning. Teams may begin work without a shared objective, realistic capacity, or an explicit basis for prioritization.

Ceremonies without adaptation. Regular meetings and iterations produce limited value when findings do not alter decisions, design, or delivery practices.

Output substituted for outcome. Large numbers of completed tasks or features may coexist with poor user adoption and little measurable business improvement.

Unmanaged dependencies. Teams may optimize their own throughput while shared platforms, suppliers, and approval processes constrain end-to-end delivery.

Weak engineering discipline. Frequent delivery can increase defects and operational risk without automated testing, integration practices, secure design, and quality controls.

Unclear decision rights. Conflicts arise when sponsors, product owners, project managers, and technical leaders have overlapping or contradictory authority.

Forced use across unsuitable work. A single method applied without tailoring can create avoidable overhead or weaken accountability.

Illustrative example

Consider a hypothetical public-service organization replacing a complicated online application process. The project has an approved budget, security requirements, and a fixed date for a regulatory change. Rather than designing every screen in advance, the team tests short increments with representative users and measures completion rates, accessibility issues, and processing errors.

The project sponsor retains funding and policy decisions, while the product team adjusts the backlog based on evidence. Architecture and security reviews occur throughout development; deployment remains subject to required controls. If testing shows that a proposed feature adds complexity without improving the service, the team may remove it from the next delivery increment. The example illustrates how adaptive planning and formal governance can work together.

Relationship to adjacent disciplines

Discipline Primary focus Relationship to agile project management
Project management Governing temporary work to achieve defined objectives Parent discipline embracing predictive, adaptive, and hybrid delivery
Scrum A specific framework for complex work One possible framework used within agile project delivery
Product management Long-term value, evolution, and success of a product Can supply priorities and outcome direction across multiple projects
DevOps Collaboration and technical practices for building, releasing, and operating systems Can enable rapid and reliable incremental delivery
Portfolio management Selecting and governing a collection of investments and initiatives Allocates funding and priorities across agile and non-agile work
Change management Governing or enabling organizational and technical changes, depending on context Supports safe deployment and adoption of delivered capabilities

See also

References

  1. ↑ Project Management Institute (2026), Agile Practice Guide, second edition, July, official guide.
  2. ↑ Beck, K. et al. (2001), Manifesto for Agile Software Development, official text; Principles behind the Agile Manifesto, official principles.
  3. ↑ Schwaber, K. and Sutherland, J. (2020), The Scrum Guide, November, official guide.
  4. ↑ Project Management Institute (2026), What's New in the Agile Practice Guide – Second Edition, 2 September, PMI article.
Retrieved from "https://cio-wiki.org//index.php?title=Agile_Project_Management&oldid=19493"