“We will be using the Scrum framework and I need you to help the client’s Product Owner with refining User Stories and Acceptance Criteria” – Bernard, one of the companies most experienced project managers, said.
I worked with Bernard on several other projects, and always liked working with him. However, I was a little hesitant to join this project. I had limited experience in Scrum and never really worked with User Stories. I remember asking him “What do you mean with Acceptance Criteria”?
Long story short, I joined the project and started my learning journey on User Stories. Since then, I have seen many ways of creating and collaborating with User Stories. Even within the same company, you will often see differences in how User Stories are written and used on 2 separate projects.
So why are some User Stories only described in a few words while others have elaborate descriptions, acceptance criteria and additional documentation? Are there any golden rules to guarantee that we uncover at least 80% of the requirements and expectations? What makes a good User Story? And is there an ideal template or format for a User Story? – Thank you, Ana Grou, for some of your questions.
In this article, I will share my best practices on how to create and collaborate on User Story components to ensure the whole team gets a shared understanding of the requirement and the next stages of solutioning and implementation are set up for success.
Who writes User Stories?
Adding requirements to your Product Backlog is usually the Product Owner’s responsibility. However, in the many years that I have been implementing Dynamics 365 and Power Platform projects, I have frequently seen this task being shared between multiple persons.
Most often a Business Analyst will work closely with the Product Owner to help describe and analyse requirements.
The Business Analyst, with the help of the Product Owner, will create the initial User Story and will then collaborate with the Dev team to complete the additional details until the User Story is “Ready” to be assigned to the Dev Team so that it can be worked on.
On other occasions I, myself, as a vendor, created and maintained User Stories for my clients. However, even in those scenarios, I made sure that my client’s Product Owner was always responsible for owning and prioritizing requirements. You can do this by reviewing the User Stories with the Product Owner and getting their formal approval to proceed with the story development.
What are User Stories
As we are implementing Dynamics 365 or the Power Platform for users or end clients, each interaction they have with our system can be captured as a “User Story”.
A User Story is an informal, natural language description that captures the essence of a requirement from the point of view of the user. It’s important that User Stories capture the WHO, the WHAT and the WHY of the requirement and not the HOW.
My top 10 User Story creation and collaboration components
Below is a sample User Story in Azure DevOps that I have decomposed into individual components.
1. Title
Short title for the User Story.
- Include a number in the title if there is a logical sequence to your stories within an epic.
- Keep the title short as it makes it easier to understand the story when viewing it in your Product Backlog structure.
2. State
The state is used to define the current requirement stage within the item lifecycle. I use the following states:
- New
- In Analysis
- In Dev
- In Test
- In UAT
- Done
You can find more details in my articles about the requirements life cycle.
3. Description
Description of the User Story written in the format of “As a [Role], I want [Action]… so that [Benefit]”.
4. Acceptance Criteria
Additional details to help you confirm a shared understanding and agreement of the story.
I like the format where each scenario is defined using the:
Given the context of the action
When the action is performed
Then the following observations will occur.
You can also include links to additional documentation.
5. Discussion
Use the discussion section to document your collaboration. Ask questions and capture comments as the story evolves over time.
If you are using Azure DevOps Boards, you can use the following signs to help you collaborate:
- “@” to tag someone so that the person gets notified by email.
- “#” to reference another User Story.
6. Dev effort
Dev effort will:
- Help you better plan the delivery of the User Story within a Sprint.
- It forces your Dev Team to clarify any misunderstanding before committing to delivering the User Story.
- Depending on the Agile maturity of the team you work with, your story points can relate to time needed (for less mature teams) or effort. Effort is preferred since the time needed for a story point will most likely decrease as the project progresses (higher burn rate) due to the team getting more familiar with the project.
7. Priority
A critical element to help with planning the sequence of delivering User Stories and one of the most important tasks of the Product Owner to determine. Essentially, we want to make sure that high-priority items get addressed first.
8. Additional documentation
URL to a SharePoint folder where we can store additional documentation for the User Story. See below some examples of additional documentation that I find useful when documenting stories.
9. Parent Features or Epics
Helps you link the User Story to a parent Feature of Epic. You can find out more about how I usually structure my requirements.
10. Related User Stories
Use this to add related User Stories to avoid repeating the same information across multiple stories. In Azure DevOps Boards, each time you tag another User Story using the “#” hashtag, that item will be added to the Related section.
Additional Documentation
This is where I find it handy to have additional documentation depending on the nature of the User Story. Usually, a combination of these is helpful.
Process Flow Diagrams: Process flow diagrams are a simplified representation of a process. There is always a start and an end where actions are being done by different actors.
TIP: Often a Process will be too large to be delivered in 1 User Story. Use a parent Feature or Epic as the container to describe your process, where User Stories are the steps within the process.
Business Rules: “If the User Story refers to business rules that are better documented in tables, I would use an external Excel Sheet that I can reference in my Acceptance Criteria.” Sibylle Marxgut
Personas, Business Units and Security Roles: “Those are often documented in an external Excel sheet, so that we can see the users with their related roles and the business units’ hierarchies.”
Ana Grou
User Interface mock-ups: I find mock-ups handy for User Stories involving a Portal or when the User Interface plays a significant role in delivering the solution. Some examples might be:
- Power Apps Portals layout
- Showing / Hiding a range of fields based on custom logic
- Mock-up of a PCF or Custom Page control
You can also find more info in my article about Requirements details including attachments – Azure DevOps integration with MS Teams and SharePoint.
Other TIPS when working with User Stories
Concept of 3C
- Card: Capture the User Story on a Card or in a tool like Azure DevOps Boards.
- Conversation: Make sure to discuss the User Story with your Product Owner, SMEs and Dev Team. You can capture the feedback and key discussions point in the “Discussion” area.
- Confirmation: Add the Acceptance Criteria to your User Story to confirm the shared understanding and expected outcome of the User Story.
Use the Invest mnemonic
The INVEST mnemonic for Agile software development projects was created by Bill Wake as a reminder of the characteristics of a good quality User Story.
- Independent: They add value on their own and can be implemented without dependencies on other stories. If you find that some stories are tightly dependent on each other like case creation and case assignment, then I usually add a sequencing to the User Stories. Case creation is first then we work on a case assignment.
- Negotiable: Until the story is committed for work, it can be re-written, changed or canceled at any time.
- Valuable: It delivers value to users of the system.
- Estimable: You must be able to estimate the size of a Story in story points. This will help you make sure that the story is descriptive enough and understood by the development team.
- Small: The story should be small enough to be delivered in 1 sprint. You can use this great Story Splitting Flowchart by Humanizing Work if your User Story does not fit within 1 single sprint.
- Testable: The story should have enough information to allow a tester to develop test cases.
Split the technical parts from the User Story
“When writing a User Story, you must be able to split the technical parts from the User Story. If the story requires data cleaning or mapping, collaborate with your dev team to document the technical requirement in a separate task or technical User Story. The focus of a User Story is to gather valuable information about the expected user experience” Bonus: Common mistakes when writing a user story by Ana Grou
Definition of “Ready”
Having an idea of a definition of ready can help everyone on the team better understand what is required for the Dev Team to feel confident that they can successfully deliver the user story.
You can find more details in my article about Definition of Ready For your Dynamics 365 or Power Platform Project.
Contributors:
- Ana Grou – Dynamics 365 Functional Consultant
- Anne Dubelaar – Program Manager, Team Lead and Strategy Coach
- Sibylle Marxgut – Senior Business Analyst and Web Developer
Great article on a subject not often fully understood by all the different parties involved in D365 projects.