From BRD to Azure DevOps: Automating the Path from Requirements to User Stories

At Evertec, one of my most interesting challenges has been rethinking how business requirements travel from a document into a development team’s backlog. Business Requirement Documents (BRDs) are often written for stakeholders, not for developers — so by the time requirements reach Azure DevOps, a lot of clarity gets lost in translation.

My mission: design a BRD structure that could be converted directly into Azure DevOps work items, and explore automation to do the heavy lifting.

Designing a BRD That Maps to Work Items

Instead of treating the BRD as a free-form narrative, I restructured it so every piece of content has a clear destination in Azure DevOps:

• Epics: The high-level business goals driving the initiative.
• Features: The major capabilities that support each goal.
• User Stories: Specific, testable behaviors written from the user’s perspective.
• Tasks: The concrete steps a developer or analyst needs to complete.

This mapping means a well-written BRD isn’t just a reference document — it becomes the backlog itself.

Writing Requirements Developers Can Actually Use

A structure is only as good as the content inside it. For each requirement, I worked with:

• QA-oriented acceptance details so every story can be tested without guesswork.
• Expected behaviors, flows, and messages describing exactly what the user should see.
• Conditions and auto-actions that define how the system reacts in each scenario.
• Differences against current behavior so developers know what is changing, not just what the end state looks like.

Automating with Power Automate

The most exciting part: building Power Automate concepts and proof-of-concept logic to extract structured requirement data from Word, PDF, and HTML content. The goal is to support automated user-story creation — taking a structured BRD and generating the corresponding Azure DevOps work items with far less manual copy-paste.

Lessons Learned & Takeaways

This project sits exactly where I like to work: at the intersection of technical writing, process design, and automation. A document is never just a document — it’s data waiting to be structured. When you design content with its destination in mind, you save every team downstream hours of interpretation work.