In Part 5, I used Copilot to review the business context and help develop the requirements and architecture. That work is now saved in the repository, including the decisions we made and the questions that still need answers.

Now I need to turn that information into work I can actually build. I use GitHub issues for that. The documents explain the solution, and the issues track the work needed to deliver it.

Use the Analysis From Part 5

I start with the same three files we saved in Part 5:

  • /docs/requirements/requirements.md
  • /docs/architecture/solution-architecture.md
  • /docs/decisions/decision-log.md

I want Copilot to use these files to work out what needs to be built. Related requirements help define the epics. The architecture helps break each epic into smaller pieces of implementation work.

This is where the requirement IDs become useful. I can follow a requirement from the document into the issues that implement it. One epic may cover several requirements, and one requirement may need more than one issue.

I still keep the original discovery material. If a requirement does not match the meeting notes or an email decision, I want Copilot to point that out so I can resolve it before we build around the wrong information.

Follow One Requirement Into the Backlog

For example, say the grant-management requirements state that a grants officer must provide the requested amount and project summary before submitting an application for review. I record that as REQ-001 and link it to the meeting notes where the rule was agreed.

Here is how that example moves from the analysis into the backlog. In the project, I would use the actual requirement and its source.

Output from Part 5 How it feeds Part 6
Confirmed requirement REQ-001: prevent submission when the requested amount or project summary is missing. Defines the required behavior and gives the issues a requirement reference.
Approved architecture: store applications in Dataverse and provide an internal model-driven app. Identifies the implementation areas: application fields, form experience, and submission validation.
Business outcome: grants officers can prepare complete applications and send them for review. Becomes the proposed “Grant application intake” epic.
Required behavior plus the approved design. Produces bounded child issues, including “Enforce required information before submission,” linked to REQ-001.
An unresolved decision about who receives submitted applications. Becomes a clarification task or an explicit dependency on routing work; Copilot must not invent the recipient.

For that validation issue, an acceptance criterion could be: “Given an application with no project summary, when the grants officer attempts to submit it for review, submission is prevented and the missing information is identified.”

I now have something I can test. The requirement tells me what needs to happen, the architecture helps determine where it belongs, and the issue describes the change. The related data and form issues can reference REQ-001 as well.

Before Copilot creates the issues, I want to review how they connect to the requirements. Did we miss anything? Is it adding work we never agreed to? Are there questions we need to answer first? This is much easier to fix while reviewing the proposed backlog.

Use Parent Issues as Epics

I use an epic to describe a larger outcome, then create smaller implementation issues beneath it.

In GitHub, I represent that epic with a parent issue and attach the implementation issues using the sub-issue relationship. An epic label can help identify those parents, but a label alone does not create the hierarchy.

For the Grant application intake example, the child issues might cover the Dataverse application table, the intake experience, submission validation, and access controls. The approved design determines which of those issues we actually need.

The parent issue explains the business outcome, scope, success criteria, and links to the approved requirements and architecture.

Make Each Issue Ready for Implementation

I want each issue to contain enough information for another developer, or Copilot, to pick it up and understand what needs to be done.

I include:

  • The business requirement and its source.
  • The parent epic.
  • What is in scope and explicitly out of scope.
  • Dependencies and decisions that must be resolved first.
  • Acceptance criteria that describe observable behavior.
  • Validation expectations.
  • Relevant repository paths and architecture decisions.
  • The appropriate Power Platform skill, where known.

“Build the app” does not give me much to work with. I want the issue to explain which part of the app, what it needs to do, who can use it, and how I will know it works.

Ask Copilot to Draft the Backlog

I ask Copilot to draft the epics and child issues using the project documents. I want to review that proposal before it creates anything in GitHub.

Here is the prompt I use. Change the file paths to match your repository.

Review the repository instructions and the following project documents:
- /docs/requirements/requirements.md
- /docs/architecture/solution-architecture.md
- /docs/decisions/decision-log.md

Use the confirmed, approved first-release requirements and approved
architecture as the basis for planning. Read their cited discovery sources
where needed to understand or verify a requirement.
Review existing GitHub issues to avoid duplicate work.

Propose a GitHub backlog organized into epic parent issues
and bounded implementation sub-issues.

Group related requirements by business outcome to propose the epics.
Use the approved architecture to identify the implementation work.
Preserve the existing requirement IDs; do not generate new IDs
for the same requirements.

For each epic, include:
- the business outcome, scope, and completion criteria,
- the requirement IDs it covers.

For each implementation issue, include:
- the parent epic,
- requirement IDs and source document paths or sections,
- scope and exclusions,
- acceptance criteria derived from the required business behavior,
- dependencies, including unresolved decisions,
- validation expectations,
- relevant repository paths and architecture decisions,
- the appropriate Power Platform skill where known.

Include a mapping of requirement ID -> proposed epic -> proposed child issues.
Identify approved requirements with no planned coverage.
Explain the approved technical reason for any enabling work that
does not directly implement a business requirement.

Keep unconfirmed requirements and later-release work separate.
Flag conflicts, duplicate work, and unresolved decisions.
Propose clarification tasks for blocking questions instead of
inventing answers or treating affected implementation work as ready.

Do not implement components or create GitHub issues yet.
Present the proposed backlog and requirement mapping for review.

I compare the proposal with the requirements we saved in Part 5. Every requirement in the first release needs to be covered, and I should be able to explain why each issue is there. I also check the order of the work and whether the acceptance criteria will actually show that the requirement has been met.

If Copilot has filled in a missing decision with an assumption, this is where I catch it.

Once I am happy with the proposal, I ask Copilot to create the approved epics and child issues in the project repository using the GitHub tools available in my setup.

I specify the repository and GitHub Project explicitly. I ask it to attach each child to its parent using the sub-issue relationship and report the resulting issue URLs.

If the tooling cannot create the relationship, I complete that step in GitHub's interface. A list of issue links in a comment is not a substitute for the hierarchy.

Then I verify that each issue has the correct parent, scope, acceptance criteria, and Project status.

Keep Documentation and Work Tracking Connected

The architecture stays in the repository so changes can be reviewed with the solution. The issues link to those documents and capture the implementation work, discussion, and status.

The architecture document can explain the overall delivery order. I keep the individual tasks and their status in GitHub so I do not have two backlogs to maintain.

When a requirement changes, I update the relevant documentation and affected issues so the two continue to describe the same solution.

Choose the First Issue

At this point, I have a backlog I can work from. I choose an issue that has clear acceptance criteria and is ready to start. If it depends on something that has not been built or decided yet, I start with that work first.

In Part 7, I will give Copilot the selected issue and follow it through implementation, validation, and a pull request.

Resources