Featured service

Technical Backlog Architecture and Delivery Readiness

A product vision is not ready for implementation simply because it has been discussed, documented, or entered into a project-management system. The delivery team still needs a shared understanding of the intended product, the boundaries of each capability, the expected user interactions, and the conditions for acceptance.

I provide a focused product-management and business-analysis service that converts those inputs into a structured backlog foundation before development begins.

Discuss an Initiative View All Services View Portfolio

Service boundary
This service focuses on product discovery, work-item architecture, stakeholder alignment, requirements definition, acceptance criteria, and delivery-team refinement. It does not include engineering implementation, technical task execution, integration testing, production deployment, or product launch unless those activities are separately agreed.

Work-item hierarchy

The work is organized around three levels. Each level has a different purpose and a different owner.

Epic
└── User Story
    └── Task

Epic: A high-level business capability or feature that defines a meaningful area of product scope.

User Story: A discrete system interaction described from the point of view of a specific user type.

Task: A technical implementation step created by the unified delivery team during the delivery phase.

This service defines the Epics and User Stories. Technical task breakdown and day-to-day engineering execution remain delivery-team responsibilities.

The five-step process

The sequence moves from understanding the available information to creating a backlog foundation that stakeholders and the delivery team can review, refine, and use for implementation planning.

Discovery

First, I ingest and synthesize the relevant documentation that has been provided. This may include product documents, repository files, email attachments, meeting notes, existing requirements, and other available source material.

The purpose is to identify:

Requirements that are already defined
Requirements that are implied but not yet documented
Conflicting assumptions
Open questions
Potential scope boundaries
Information that requires validation with a domain expert

Output: A synthesized understanding of the current product vision, known requirements, open questions, and initial scope considerations.

Work Item Stubs

I then create the initial work-item structure. I begin at the User Story level by identifying the expected interactions between users and the proposed system. I create Epic work items to organize those User Stories into related collections of functionality.

At this stage, the work items are intentionally draft-level. The purpose is to make the expected product scope visible before detailed definition begins.

Output: An initial Epic and User Story structure covering the identified system interactions.

Epic Work Item Details

I collaborate with designated domain experts and product stakeholders to define the Epic-level intent. These discussions may occur through meetings, email, messaging, or structured questionnaires, depending on stakeholder availability and the needs of the initiative.

For each Epic, I document:

The intended capability
The business purpose
The expected scope
The relevant boundaries
The conditions that must be proven for success
Any decision about inclusion in the initial product increment or deferral to a later increment

Epic-level acceptance criteria represent the agreed contract for the capability. Those criteria are established with the appropriate domain experts and product stakeholders.

Output: Defined Epic work items with agreed scope and parent-level acceptance criteria.

User Story Work Item Details

After the Epic work items have been defined, I complete the User Story work items beneath them.

Each User Story includes:

The applicable user type
The user's need
The interaction with the system
The purpose of the interaction
The expected result
Draft acceptance criteria

The User Story acceptance criteria are initially drafted for review by the delivery team. They elaborate on the parent-level Epic acceptance criteria without changing the agreed Epic contract.

Output: Detailed User Stories with descriptions and draft acceptance criteria.

User Story Refinement Sessions

Finally, I collaborate with the unified delivery team, including development and QA responsibilities, to review the User Story descriptions and draft acceptance criteria.

The goal is for the delivery team to reach a shared understanding of:

What each User Story is intended to accomplish
What is included and excluded
What must be proven for acceptance
Whether the acceptance criteria are understood and achievable as written

I revise the User Story descriptions and draft acceptance criteria as needed to support that consensus. User Story-level details may be added, removed, or edited during refinement.

Epic-level acceptance criteria remain controlled by product stakeholders and designated domain experts. They should only change when those stakeholders reach a new consensus.

Output: A refined backlog foundation prepared for technical task breakdown, estimation, sequencing, and implementation planning.

What this service provides

Primary deliverables

Structured Epic and User Story hierarchy
Epic-level capability definitions
Agreed scope and capability boundaries
Epic-level acceptance criteria
User Story descriptions
Draft User Story acceptance criteria
Documented assumptions and open questions
Delivery-team refinement outcomes
Backlog foundation prepared for technical task breakdown

Useful for

Early-stage product teams
Organizations preparing an MVP
Initiatives with unclear or changing requirements
Domain experts communicating with technical teams
Existing delivery teams needing a stronger backlog foundation
Organizations preparing to engage an engineering team

What happens after this service

The unified delivery team uses the refined User Stories and acceptance criteria to create technical Tasks, estimate the work, identify dependencies, sequence implementation, and prepare the delivery plan.

That transition is intentional. Product-management definition establishes what the system must accomplish; delivery-team task planning determines how the team will build and verify it.

Outside the scope

Software engineering implementation
Technical task execution
Automated or manual test execution
Integration testing
Production deployment
Product launch
Ongoing product ownership after refinement

Those activities may be addressed through a separate engagement if needed.

Engagement size depends on the initiative.
The appropriate level of effort depends on the number of capabilities, stakeholders, existing documentation, unresolved decisions, and delivery-team availability. I scope the engagement after an initial discussion and review of the available materials.

Start a Conversation Return to Services