Requirements Workshops for Dynamics 365 or the Power Platform

I just walked into the board room to facilitate a requirement workshop for a relatively new client. I am a little anxious about this workshop somehow. The IT manager has flagged that the subject of the workshop is complex and that requirements are not “really” clear yet.

I also know that some of the attending stakeholders are annoyed as they consider this workshop to be a waste of time. For them, the requirements are clear as they were discussed previously between IT and the Business. This was before I joined the project.

After I covered the first few minutes with an introduction, I could feel that some stakeholders were already starting to get distracted. I carried on, trying to remain calm, and asked my first question to clarify assumptions I had made.

After a long pause, one of the stakeholders started to give his opinion on how the logic behind the requirement should work. To my biggest surprise, another stakeholder jumped in the conversation with a completely different view. Not long after, many stakeholders were passionately discussing the requirement, each one giving their own view of how it should work.

I couldn’t believe what was happening. Only 10 minutes into the workshop and already on the first assumption we have ambiguous and unclear requirements.

What are Requirements Workshops

Requirements workshops are meetings where 2 or more stakeholders come together to discuss requirements to solve a business problem or achieve an outcome.

A requirements workshop can be defined as a structured and facilitated event for getting carefully selected stakeholders together to discover, refine, prioritize, validate and discuss requirements. A skilled facilitator usually manages workshop sessions.

Requirements Workshop Technique: Exploring the Power of Collaboration

Below are the steps I usually follow when preparing and running requirements workshops. Those assume that you have at least some high-level requirements to start with.

If you don’t have requirements at all, you can read my article about the Value Stream Mapping which is the perfect tool to start building your initial list of requirements and create your Product Backlog.

Before the workshop

REFLECT

Take some time to read and reflect on the requirements

1. Do you understand the meaning of the requirement?

• What problem are we trying to solve?
• Who will benefit from this requirement?
• Why is this requirement important?

Tip: I often use Socratic Questioning to guide my thought process.

2. How would you build the requirement?

Based on your current understanding of the requirement, ask yourself how you would solve / build the solution for this requirement. Doing so will help you uncover the questions you need an answer for.

3. Write down the questions to ask about the requirement
Repeat steps 1 & 2 for each requirement and write down all the questions you need to ask during the workshop.

Tip 1: Again, you can use Socratic Questioning to make sure you ask the right questions.
Tip 2: If using a tool like Azure DevOps, you can write down your questions in the discussion section of the item. You can also tag (@username) so that they can review your questions before the workshop.

4. Group requirements in similar topics

If requirements are not yet grouped in “Categories” (often called “Features” or “Epics”), group them so that they can be addressed in the same workshop.

Tip: Check out my article about Structuring Requirements.

PREPARE

1. Invite the right audience

Who is/are the best subject matter experts to help answer your requirements questions?

Tip: The Product Owner is often the best person to help you invite the right audience for your workshop.

2. Prepare draft diagrams

Use diagrams to illustrate ideas and help you understand and discuss the topics during the workshop. Below are the diagrams I often use:

• Use Case Diagram
• Conceptual Diagram
• Journey Map
• Entity Diagram

Tip: Check out my article about My Go To Diagrams

3. Book the meeting and send out the agenda

Try to always send the agenda of the meeting beforehand. I often send the list of Requirements I am planning to discuss.

Tip: When using Azure DevOps, I send the list of Features / User Stories I plan to discuss during the workshop.

Durint the workshop

INTRODUCE

1. Workshop purpose

Have a slide to remind everyone of the purpose for the workshop. Think about your audience and “what’s in it for them”. Your SMEs (Subject Matter Experts) are dedicating time to attend your workshops, so it should be clear to them about the benefits they get when providing input during the workshop.

Tip: Example I would use:
The purpose of this workshop is to get to a “Shared Understanding of Requirements”. This will provide the following benefits:

• We will design better solutions –> SMEs will get solutions better tailored to their needs.
• It helps us write User Stories with clear Acceptance Criteria so that the Dev Team knows what is expected –> Less frustrations and rework when users start using the solution.
• We will be demoing you the standard features of the system –> SMEs get additional training and increase knowledge about the platform (Dynamics 365 or the Power Platform).

2. Key Success Factors

Key success criteria can be seen as the key outcomes expected from using Dynamics 365 or The Power Platform. They also act as guard rails to help you stay on track during the “Project Delivery”.

Tip: Example from past projects:

• Dynamics 365 to fully replace the current [legacy platform/system name].
• Have access to client’s communication history through recording of all in person, by phone, email and chat communication.
• Capture and manage cases in one central location.

3. Lifecycle or Journey

When discussing requirements or solution ideas, I often prepare a slide with the scenario “story” that set the context of the requirement. By doing so, I set the context and give my audience time process the scenario I am going to cover before diving to details and showing them screens in Dynamics 365.

Tip: Check out my article about My Go To Diagrams

ACT

4. High Level Concepts

One of the diagrams that I use the most is the “Conceptual Diagram”. Which is a graphical representation of the building blocks or features that we are implementing using Dynamics 365 or the Power Platform. The conceptual diagram helps to remind everyone what is the big picture and the solution about.

Tip: Check out my article about the Conceptual Diagram.

5. Review / discuss / demo each requirement

Go through your list of requirements and discuss the details of your requirements. You can use various diagrams and a sandbox Environment of the system to help everyone get to a shared understanding.

6. Ask the questions you prepared for each requirement

For each of the requirement, ask the questions you prepared beforehand to stimulate discussions and clarify assumptions.

After the workshop

ADAPT

1. Update Epics, Features and User Stories

With the help of the Product Owner and/or Business Analyst on the project you will need to update each requirement with the details you captured during the workshop. The below are some of the Product Backlog changes you might need to do:

• Create new User Stories.
• Split User Stories in multiple User Stories.
• Convert a User Story to a Feature or Epic (if more complex than expected) and create child User Stories underneath.
• Move User Stories to other Features or Epics.
• Merge User Stories if you realize that 2 stories are similar.
• Add relationship / dependencies between User Stories and or Features/Epics.

2. Add Acceptance Criteria to User Stories

For each User Story, add details to help you confirm a shared understanding and agreement of the story. Check with your Product Owner and/or Business Analyst who is best placed to add Acceptance Criteria to User Stories.

Tip: I like to use the Given – When – Then formula to write Acceptance Criteria.

3. Update your diagrams

Update your draft diagrams with the information you collected after the workshop.

VALIDATE

1. Design solutions to address requirements

Use a sandbox environment to prototype your solution designs.

Tip: Think about the specific solution components you need to solve the requirement: Entities, Fields, Views, Forms, Logic, Charts, Apps, etc.

2. Challenge complex requirements

Challenging requirements is about making sure that we build something that the company really needs, and not what a Product Owner or SME “wants” or “thinks” that the company needs. Try to simplify solutions and stick as much as possible to standard features to avoid a maintenance nightmare in the future.

Tip:  If you are uncertain about how your client will react to you questioning their requirements, ask for permission to challenge them beforehand. In most situations your client will be pleased you ask the question and respond that they are happy for you to challenge them. With the permission up front they will feel a lot less defensive when you do.

3. Is your requirement READY for DEV?

The definition of ready helps you define if you have enough details in your Story to start the Dev work.

Tip 1: This is a definition of Ready I would use on my project:

• A conversation has happened about the story.
• Acceptance Criteria are defined and understood so that test cases can be written.
• Dependencies to other user stories are known and resolved or can be resolved during the sprint.
• The User Story can be estimated and delivered in 1 sprint. Otherwise, the story must be split.
• The Product Owner has approved the Story and the Acceptance Criteria.

Tip 2: Check out my article about Challenging Requirements. And reference to some other examples from community members.

Summary

I hope that you found this article helpful and that you can benefits from some of those tips when running your own workshops. Note that this is my way of running workshops and that you will need to experiment and discover what best works for you.

Please do let me know how you run your workshops. What are the similarities with my process? What do you do differently? You can use the comment section below to add your feedback and comments so that we can all learn from each other 😊