“Wait a minute! So you are telling me that Functional Consultants FROM THE IMPLEMENTATION PARTNER are writing the User Stories for the client?” – I asks with astonishment.

“Well, yes” says Simon, the Scrum Master on the project. “The Business Analyst, with the help of the Product Owner, will write up the business requirement in a Feature under an Epic, and then the Functional Consultants write the User Stories for that Feature”.  

“Hmmm… that’s new to me” I say. “From experience, the Business Analyst will usually write the User Stories. Then the Dev Team helps with the elaboration of the User Story and recommends solutions to meet the business requirement”.

“Well, yes… The Business Analyst will help with the story elaboration, but the Functionals create and write the user stories in our project. We need to make sure they are understood by the developer that will implement it” Simon tells me with assurance.

“OK…” I say, “For me this makes no sense, but I am willing to see how you guys work this way”.

The approach was surprising to me. I (acting as the Lead Functional Consultant) have written User Stories for my clients in the past, but only when my client was new to User Story writing or because there was no Business Analyst.

This, on the contrary, was a good size project, for an organization that was familiar with Agile, and both the Business Analyst and Product Owner were assigned to the project full time.

As the project progressed, I learned that it does not really matter who creates the User Story. The key is to have the whole team collaborate and discuss the User Story so that we get to a shared understanding of the requirement. 

In this article, I’d like to dig into this topic and define “Who collaborates on which part of the User Story”, based on my experience of what works. It is a continuation of the article I wrote about User Story key components in which I took a detailed look at the User Story components I typically use on my projects.

Who collaborates on which part?

The illustration below depicts how each role interact with the User Story key components including a level of engagement using a percentage indicator. The percentages are only indicative as for each User Story you might have a different level of engagement per component.

Let’s detail how each role collaborates on each part of the Story.

The Product Owner and the Business Analyst

The Product Owner (or PO) oversees the development of the product and ensures it meets the organizational needs. The PO sets the overall vision of the product, manages, and prioritizes product backlog items and makes sure the requirements are understood by others in the team.

The Business Analyst (or BA) helps the PO define business problems by collecting and analysing information. Once the issue is clearly understood, they outline business requirements for a solution and ensure the delivered solution meets the organizational needs. ​

The Product Owner (PO) and the Business Analyst (BA) work hand in hand to define the business requirements and prioritize the product backlog.

• Description: The PO/BA define the business requirements written in the format of “As a [Role], I want [Action]… so that [Benefit]”.
• Priority: The PO sets the priority of the requirement.
• Acceptance Criteria: The PO/BA work closely with the end users to document the Acceptance Criteria for the User Story. The PO/BA, with the guidance from the FC/SA, somewhat adapt the Acceptance Criteria to the platform capabilities.
• Parent Epic/Feature: The PO/BA are most likely the best persons to define and maintain the Product Backlog structure by linking the Epics, Features and User Stories together. You can find more information on how to structure requirements in this article I wrote: Structuring requirements in DevOps.
• Documentation: Additional documentation like Business Rules or screen mock-ups are provided by the PO/BA.
• Related Stories: While working on the User Story, the PO/BA are likely to identify any other related User Story.
• Discussion: All members of the team use this area to discuss the User Story details.

The Functional Consultants and Solution Architects

The Functional Consultant (or FC) works closely with the PO & BA to understand the business requirements and recommend optimal solutions using Dynamics 365 or the Power Platform. The FC is supported by the Solution Architect when it comes to design decisions.

The Solution Architect (or SA) leads project implementations by addressing how the solution will deliver on the business and technical needs of that organizations. The Solution Architects supports the implementation team with making design decisions across all the implementation stages.

The Functional Consultants (FC) and Solution Architects (SA) try to understand the requirements and propose appropriate solutions to meet the company needs.

• Acceptance Criteria: The FC/SA work with the PO/BA to refine some of the Acceptance Criteria based on the platform capabilities.
• Documentation: Design documentation are stored in this area.
• Design: Where design specifications are defined.
• Parent Epic/Feature: The FC/SA advise and guide the PO/BA on how best to maintain the Product Backlog structure by linking the correct User Stories to the right Epics and/or Features.
• Related Stories: While designing the User Story, the FC/SA are likely to identify related User Stories.
• Discussion: All members of the team use this area to discuss the User Story details.

The Testing Team

The Test Team oversees the testing strategy. Testers create test plans and test cases to support the full testing lifecycle of the project. The test lead plans and coordinates testing activities across the various testing types (functional, integration, end to end, UAT, etc.).

• Estimates: The Testing Team estimates the effort required for them to create the test cases and perform the testing activities.
• Test Cases: The Testing Team writes the test cases for each user story.
• Discussion: All members of the team use this area to discuss the User Story details.

The Dev Team

The Developer Team (DEVs) is responsible for all phases of the development life cycle. The DEVs will design, configure, code, and unit test the application to meet the business requirements. The FC and SA are often considered part of the DEVs.

• Estimates: The Dev’s estimates the effort required for them to build the story.
• Design: The Dev Team helps the FC/SA design the User Story.
• Discussion: All members of the team use this area to discuss the User Story details.

There you have it. It might look like a lot of work to get the right parties involved in different elements of your user story, but it will pay off for the success of your project.

And as always, reality is hardly ever perfect, so use this as a guideline and adapt to the situation you are in and the resources you have available.

“Sometimes the PO will not have a BA to help and will not have enough time to write the description of the User Story. As a result, and to not impact the quality of the User Story, more parts must be taken over by SA/FC, which takes away their time for other topics.”

by Lars Martin – Microsoft FastTrack Recognized Solution Architect Dynamics 365 CE | Power Platform Specialist

So how do your team collaborate and elaborate User Stories? What do you do differently? Use the comment section below to add your feedback and comments so that we can all learn from each other 😊