Prioritizing Deployment Requirements by Impact, Risk, Effort, and Dependencies

Hello! Last time, you turned “Use AI to answer tickets faster” into testable requirements: a sourced draft when approved policy supports one, no draft when it does not, agent control over sending, and approval for review-required replies. Agreement on what to build does not mean everything can—or should—be built at once.

In this lesson, you’ll decide what belongs in an initial deployment and what can wait. You’ll weigh customer impact, delivery and operational risk, engineering effort, and dependencies. The goal is a sequence you could explain to a customer and a delivery team, not a spreadsheet that hides difficult decisions behind a score.

---

Start with the deployment boundary, not a ranking

Suppose the support-assistant pilot has a fixed delivery window. A policy owner will provide a set of current, approved documents; agents will request drafts for eligible tickets; and review-required tickets are included. These are the illustrative pilot decisions carried forward from the previous lesson.

Now imagine someone proposes three additional capabilities: collecting agent feedback on suggestions, expanding the assistant to more ticket categories, and opening cited policy sections in a side panel. Each might be valuable. But “valuable” does not answer whether it belongs in this pilot, and a low-effort addition does not necessarily outrank a safeguard.

Atlassian’s Product backlog: Tips for creation and prioritization provides a useful first pass. Its four-step review considers customer need, urgency of feedback, implementation complexity, and dependencies.

For this pilot, establish the boundary before comparing effort:

• Release gate: A condition that must hold before the selected pilot users can safely use the workflow. If review-required tickets are included, blocking unapproved sends is a gate—not an optional enhancement.
• Enabling work: Work that makes a requirement possible. Obtaining a verified set of current, approved policies may have little visible value on its own, but the drafting and withholding requirements rely on it.
• Scope candidate: An improvement you can compare with other improvements once the gates and prerequisites are understood.

This distinction prevents an attractive side-panel feature from displacing an essential approval rule merely because the side panel is easier to demonstrate.

---

Make the four inputs explicit

Impact asks what changes for the customer if an item is delivered. For the pilot, assess impact against the agreed objective—helping agents prepare acceptable policy replies more efficiently—not against how impressive a feature sounds. A sourced draft has direct impact; a feedback mechanism may have indirect impact by showing where drafts fail. Ask whose workflow improves, how often the relevant situation occurs, and what evidence would show improvement.

Risk has two meanings worth keeping separate. Risk of omission is the harm or uncertainty left if you do not deliver something: an unsupported policy answer or an unapproved send could make the pilot unacceptable. Delivery risk is uncertainty about whether you can build or validate it: perhaps the policy owner cannot reliably identify withdrawn documents. A high-risk item may need an early investigation, but discovering risk early does not permit an unsafe feature to go live. Risk reduction can be a reason to do work early even when that work has modest immediate user-visible value.

Effort includes integration, customer review, testing, and coordination—not just writing code. Compare items on a consistent scale and record important uncertainty. “Two days if review status is exposed by the existing system; substantially longer otherwise” is more useful than an unjustified single-day estimate.

Dependencies describe what must be true before another item can work or be accepted. The draft requirement depends on approved policy being available. The post-edit approval rule depends on the reply workflow recognizing both approval and subsequent edits. A dependency might be technical, but it might also be a customer decision, a document supply, or access to an existing system. Record an owner for external dependencies; do not silently treat them as completed engineering tasks.

These inputs answer different questions. Impact and effort help compare opportunities. Risk can identify work to investigate or safeguards that cannot be omitted. Dependencies determine which otherwise attractive orderings are feasible.

---

Use categories to protect the release, then scores to compare choices

Jama Software’s Requirements Prioritization Techniques: 7 Methods describes two complementary approaches: MoSCoW categories for agreeing what is necessary in a particular time box, and weighted scoring for comparing items against stated criteria. Read these portions with the pilot boundary in mind.

For the agreed pilot, a defensible classification might be:

Item	Pilot decision	Reason
Verified current, approved policy set	Prerequisite	Drafting and withholding cannot be validated without it.
FR-1: Sourced draft when policy supports one	Must	This is the capability the pilot exists to test.
FR-2: No draft without relevant approved policy	Must	An unsupported suggestion defeats a central acceptance boundary.
FR-3: Agent controls sending	Must	The pilot promises agent-initiated, not automatic, communication.
FR-4: Approval of final text for review-required tickets	Must	Those tickets are in scope, and their approval rule was agreed.
Agent feedback capture	Should	Useful for evaluating the pilot; feedback could initially be collected through an existing process.
More ticket categories	Won’t in this pilot	Expands coverage before the narrow policy workflow is validated.

“Must” means necessary for this agreed release, not “important in general.” If FR-4 cannot be ready, the team cannot quietly relabel it “Should.” The customer would need to approve a changed pilot boundary—potentially excluding review-required tickets and ensuring they cannot enter the suggestion workflow—or postpone that deployment.

Scores become useful after such constraints are clear. They help compare negotiable work and make assumptions discussable. One common sequencing method is Weighted Shortest Job First (WSJF), which compares the cost of delaying an item with its job size or duration:

$$\text{WSJF}=\frac{\text{cost of delay}}{\text{job size or duration}}$$

Watch the selected parts of How To Prioritize A Product Backlog? | #6, by Vibhor Chandel, for relative sizing and the WSJF calculation. Treat the numbers as comparative estimates, not precise financial forecasts.

The image below offers a quick visual intuition: high-value, low-effort items often look appealing. Its matrix is not, however, the complete WSJF calculation shown beside it. The matrix does not show urgency, risk, release gates, or prerequisites.

In particular, do not call a relative WSJF score “dollars saved.” When impact, urgency, and risk reduction are estimated on relative scales, their sum is a cost-of-delay proxy for discussion. A higher ratio suggests an item merits earlier attention among feasible, comparable choices; it does not override an approval requirement.

---

Work through the support-assistant pilot

Here is one illustrative comparison. Business and policy stakeholders estimate impact ($I$), urgency ($U$), and risk reduction or learning value ($Q$) on a consistent 1–5 scale. The delivery team estimates relative effort ($E$) using 2, 3, 5, or 8. Larger numbers mean more of that factor. For discussion, calculate:

$$\text{comparison score}=\frac{I+U+Q}{E}$$

These are hypothetical estimates, not findings from the customer. Before using them for an actual deployment, stakeholders would need to agree on the scales, assess the evidence for each rating, and revise uncertain estimates.

Item	$I$	$U$	$Q$	$E$	Approx. score
Verified approved-policy set	2	4	5	3	3.7
FR-1: Sourced draft	5	4	4	5	2.6
FR-2: Withhold unsupported draft	4	4	5	3	4.3
FR-3: Agent-controlled sending	4	4	5	2	6.5
FR-4: Approval of final text	4	4	5	5	2.6
Agent feedback capture	3	2	4	2	4.5
More ticket categories	4	1	1	8	0.8

A naïve score sort would begin with FR-3, then feedback capture, then FR-2. That is not yet a workable deployment plan. FR-3 protects a suggestion workflow that does not exist until FR-1 is integrated. FR-1 and FR-2 need the verified policy set. FR-4 needs the send-and-edit workflow to enforce approval on the final text. Feedback capture also needs suggestions to exist before it can collect useful observations.

A more defensible sequence is:

1. Resolve the policy prerequisite and its uncertainty. Confirm who supplies approved documents, how withdrawn documents are identified, and whether the required data is available in time. Test this early; if the prerequisite fails, the proposed pilot boundary may need to change.
2. Build the minimal suggestion path and its safeguards together. Implement FR-1 with FR-2 and FR-3, rather than exposing drafts to agents first and adding withholding or send control later. Their internal development order can overlap, but they are a combined gate for use.
3. Complete and verify FR-4 before including review-required tickets. Test both an unapproved send attempt and an edit made after approval, using the acceptance cases from the previous lesson.
4. Add feedback capture if capacity permits. It scores well because it could improve learning from the pilot, but its score does not displace a gate. If deferred, agree on a workable way to collect agent observations.
5. Defer category expansion. The broader coverage requires additional approved policy and evidence that the narrower workflow works; it is not needed to answer the pilot’s first question.

The sequence differs from the numerical ranking for explicit reasons: prerequisites, release gates, and the need to learn whether the foundation is sound. It also avoids pretending that “approved-policy set” is a customer-facing feature. It is enabling work whose value appears through the requirements it unlocks.

---

Turn the reasoning into a decision you can defend

A useful prioritization record can be short: state the pilot cohort and objective; list each requirement’s category, impact, risk, effort, and dependencies; name the person or group expected to resolve external blockers; and record why the proposed order differs from the score order. Mark estimates as estimates. If the customer changes which tickets are eligible, or the policy source proves unreliable, revisit the order rather than defending an obsolete spreadsheet.

In a delivery discussion, explain the trade-off plainly: “Feedback capture is relatively inexpensive and could help us learn, but we will not put it ahead of approval for review-required tickets in this pilot. The latter is a condition of using the workflow safely. If approved-policy documents are unavailable, we will raise that blocker before committing to the drafting schedule.”

That explanation does more than announce a rank. It identifies the value being pursued, the harm being prevented, the work required, and the dependency that could change the plan.

---

Conclusion

Prioritization is a constrained sequencing decision, not simply sorting features by enthusiasm or by score. Start with the agreed deployment boundary and its non-negotiable gates. Compare remaining work using impact, risk reduction, urgency, and effort; then check dependencies and revise the sequence. For the support-assistant pilot, a high-scoring optional feature still waits behind the sourced-draft and approval rules required for the selected users.

Next, you’ll specify non-functional requirements—such as latency, availability, security, privacy, and cost—that determine whether this planned workflow can operate acceptably beyond its functional test cases.