Skill Hub — AI-Assisted Analysis

Business Problem to Backlog

Transform a vague business complaint into a structured analysis backlog with priorities, owners, and dependencies that a team can execute.

What this skill is for

Business complaints arrive as vague statements: "invoices are always late," "sales orders keep getting blocked," "the integration is unreliable." This skill uses AI to decompose the complaint into a structured analysis backlog: root cause hypotheses, diagnostic tasks, prioritization, ownership, and dependencies. The output is a backlog that can be tracked in Jira, Azure DevOps, or a simple markdown table — and that distinguishes analysis work from implementation work.

When to use this skill

A business complaint arrives without clear scope or measurable impact.
You are starting a diagnostic engagement and need to structure the first weeks of work.
You need to prioritize a queue of problems and assign them to the right people.
A project is stuck because the problem statement keeps changing.
You need to separate "find out why" tasks from "fix it" tasks before committing implementation effort.

Real work situations

"Invoices are always late"

The finance director complains that invoices sit in blocked status for weeks. The real problem could be tolerance misalignment, GR timing gaps, price changes after GR, or interface mapping errors. A weak response is to assign a developer to "fix the invoice process." A strong response is to decompose the complaint into analysis tasks: verify tolerance configuration, audit GR timing patterns, review recent price changes, and inspect EDI field mappings. Only after analysis is complete can the team choose the right implementation.

"Sales orders keep getting blocked"

The sales operations manager reports repeated order blocks. The backlog must distinguish between a master data audit (are customers missing critical fields?), an incompletion procedure review (are the requirements too strict?), a replication timing analysis (does MDG lag cause partial records?), and a governance change (can we enforce completeness at entry?). Each analysis task has a different owner and a different dependency chain.

"The integration is unreliable"

The IT manager says the middleware drops messages. The backlog must separate interface monitoring setup (what is not being watched?), error pattern analysis (which errors recur and when?), ownership clarification (who responds when an IDoc fails?), and technical redesign (should we change the protocol?). The first three are analysis tasks. The last one is implementation and must wait until the analysis is complete.

Inputs required

Problem statement — the original complaint, in the stakeholder's words.
Business impact estimate — frequency, cost, or operational consequence (even rough).
Stakeholder list — who is affected, who has data, who can approve.
Existing backlog or ticket history — to see if this problem has been attempted before.
System documentation — relevant SAP modules, interfaces, or data sources.

Questions to ask

What is the measurable business impact — tickets per week, hours lost, revenue delayed?
Which systems are involved, and which transactions or interfaces touch the problem?
Who owns the data, and who owns the process?
What has already been tried, and why did it fail or not get implemented?
Is the problem new, recurring, or increasing in frequency?
What would "fixed" look like, and can we measure it?

Working method

Capture the problem statement. Record the complaint verbatim. Do not rephrase it into consultant language yet.
Validate the problem with data. Check ticket volume, error logs, or process metrics to confirm the problem is real and quantify it.
Generate root cause hypotheses. Use AI to suggest plausible root causes, but label them as hypotheses, not conclusions.
Decompose into analysis tasks. For each hypothesis, define an analysis task that would confirm or reject it. Each task must have a clear output: "evidence that X is true or false."
Distinguish analysis from implementation. If a task says "fix," "build," or "deploy," it is implementation. Rewrite it as analysis: "determine whether fixing X is the right approach."
Assign ownership. Every task needs a human owner who can execute it or access the required data. If ownership is unclear, create a separate task to find the owner.
Map dependencies. Identify which tasks must be completed before others can start. If a task has no dependencies, it is a candidate for the first sprint.
Estimate effort. For analysis tasks, estimate in hours or days, not weeks. Analysis tasks should be short. If an estimate exceeds five days, split the task.
Prioritize. Rank tasks by impact of the evidence they produce and by how many downstream tasks they unblock. High-evidence, low-dependency tasks go first.
Format for tracking. Convert the backlog into the team's tracking tool (Jira, Azure DevOps, markdown) with tags that distinguish analysis from implementation.

Decision rules

If a task requires implementation before analysis is complete, split it: the analysis task comes first, the implementation task is parked.
If ownership is unclear, create an ownership-finding task before any other work starts.
If a task has no dependencies, it can be started immediately; queue it for the first iteration.
If a task depends on multiple other tasks, schedule it after the last dependency finishes.
If an analysis task estimate exceeds five days, split it into smaller verification steps.
If a hypothesis is rejected by an analysis task, archive the related implementation tasks and inform the team.
If the problem statement changes during analysis, stop and re-validate the backlog before continuing.

Deliverables

Analysis Backlog — structured tasks with type, owner, estimate, and priority.
Dependency Map — visual or tabular view of which tasks unblock which.
Hypothesis Register — root cause hypotheses with links to the tasks that validate them.
Implementation Parking Lot — implementation tasks that must wait until analysis is complete.

Templates

Analysis Backlog

---
title: Analysis Backlog
problem: [verbatim problem statement]
project: [project name]
backlog_owner: [name]
date: [YYYY-MM-DD]
---

## Hypothesis Register
| # | Hypothesis | Evidence Needed | Validation Task | Status |
|---|------------|-----------------|-----------------|--------|
| 1 | [H1] | [what would confirm or reject] | [task ID] | [Open / In Progress / Rejected / Confirmed] |

## Analysis Backlog
| ID | Task | Type | Owner | Estimate | Dependencies | Priority | Status |
|----|------|------|-------|----------|--------------|----------|--------|
| A-001 | [task] | [Data / Process / Config / Integration] | [owner] | [hours/days] | [none / A-002] | [1-5] | [Open] |

## Implementation Parking Lot
| ID | Task | Blocked By | Tentative Owner |
|----|------|------------|-----------------|
| I-001 | [task] | [A-003, A-004] | [owner] |

Quality checklist

[ ] Every task has a human owner who has been consulted.
[ ] Analysis tasks and implementation tasks are in separate sections.
[ ] Every analysis task has a clear output: "evidence that X is true or false."
[ ] Dependencies are mapped and no task has a circular dependency.
[ ] Effort estimates are in hours or days, and no analysis task exceeds five days.
[ ] The problem statement is recorded verbatim and has not been silently rephrased.
[ ] The backlog can be pasted into a tracking tool without reformatting.

Common mistakes

Mistake: Mixing analysis and implementation tasks in the same backlog. Consequence: The team starts building a solution before understanding the problem, resulting in rework or a fix that addresses the wrong root cause.
Mistake: Assigning tasks to people who were not consulted. Consequence: The assigned owner rejects the task or lacks access to the data needed, causing delays and ownership disputes.
Mistake: Skipping validation of the problem statement with data. Consequence: The backlog targets a symptom that is not the real problem, and the analysis produces findings that no one cares about.
Mistake: Letting AI generate implementation tasks before analysis is complete. Consequence: The AI proposes solutions to hypotheses that are later rejected, wasting planning and design effort.

Weak output vs Strong output

Weak output — bad AI usage

A consultant asks AI to "create a backlog for fixing invoice delays." The AI produces a list of tasks: "Fix tolerance configuration," "Rebuild the EDI interface," "Train AP staff," and "Hire a process owner." The tasks have no owners, no dependencies, and no distinction between analysis and implementation. The team starts on "Rebuild the EDI interface" because it sounds decisive, but the real problem is a tolerance misalignment that could be fixed in a configuration session. Three weeks are wasted on interface redesign before the root cause analysis reveals the truth.

Strong output — good AI usage

The consultant uses AI to decompose "invoice delays" into hypotheses: tolerance misalignment, GR timing gaps, interface mapping errors, and price changes after GR. The AI then suggests analysis tasks for each hypothesis: "Review OMR6 tolerance settings against actual variance distribution" (2 days, FI lead), "Audit GR posting timestamps for the last 100 blocked invoices" (3 days, MM lead), "Compare EDI segment mappings for quantity and price fields" (2 days, integration lead). The dependency map shows that the tolerance and GR tasks are independent and can run in parallel. The EDI mapping task depends on the tolerance task because if tolerance is the root cause, the interface may not need changes. The backlog is imported into Jira and the first sprint is planned with four analysis tasks and no implementation tasks.

Agent instructions

AI Prompt Pattern

Role: You are a backlog decomposition assistant.
Context: I have a business complaint: [problem statement]. I need an analysis backlog, not an implementation plan.
Tasks:
1. Generate 3-5 root cause hypotheses for this complaint.
2. For each hypothesis, define an analysis task that would confirm or reject it.
3. Distinguish analysis tasks from implementation tasks. Remove implementation tasks.
4. Assign owners based on the stakeholder list: [list].
5. Map dependencies between tasks.
6. Estimate effort for each analysis task in hours or days. If a task exceeds 5 days, split it.
7. Prioritize by evidence value and dependency count.
8. Output an Analysis Backlog in the template format provided.
Constraints: Do not propose solutions before analysis. Do not invent owners. If ownership is unclear, flag it as a task to find the owner.

Agent dos

Ask for the problem statement in the stakeholder's own words before generating the backlog.
Produce the hypothesis register as a separate artifact.
Separate analysis tasks from implementation tasks explicitly.
Map dependencies and flag tasks that have no dependencies as quick starts.

Agent don'ts

Do not generate implementation tasks before analysis is complete.
Do not assign tasks to stakeholders without confirming they can execute them.
Do not skip the data validation step before decomposing the problem.
Do not present hypotheses as conclusions.

Related skills

Gap Analysis — comparing current state against target state after analysis is complete.
Process Analysis — mapping how work happens before decomposing problems.
Root Cause Analysis — structured method for tracing defects to their origin.
Stakeholder Analysis — identifying who owns the tasks and the data.

Related Atlas pages

SAP Process Audit — structured frame for cross-process audits that produce backlogs.
Invoice Verification Three-Way Match Delays — example of how a vague complaint decomposes into specific analysis tasks.

Verification status and limitations

This skill is a public working interpretation of AI-assisted backlog decomposition. It is not an official Agile, Scrum, SAP, or BABOK method. The skill assumes that the problem statement is available and that stakeholders can be identified. If the problem is genuinely unknown or the stakeholders are unavailable, the backlog will contain too many ownership-finding tasks and may not be actionable. AI-generated hypotheses are not guaranteed to be correct; they are starting points for investigation. Use this skill as a structured accelerator, not as a replacement for human judgment and stakeholder consultation.