In this article I am elaborating on how to use Azure DevOps Boards to capture requirements and build out your Product Backlog.
This article is a continuation of my series of articles about how I use Azure DevOps Boards to structure, capture and manage requirements.
Before starting to capture your requirements, I recommend you take the time to understand how you will structure your requirements first.
Please read my articles on how I usually structure requirements using Epics and Features.
Requirement ownership
Adding requirements to your Product Backlog is officially the Product Owners 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 with describing and analysing requirements.
On other occasions I, myself, as a vendor, created and maintained requirements for my client. However, even in those scenarios, my client’s Product Owner was always responsible for defining and prioritizing requirements.
Requirement origin
Requirements are being added throughout your agile project and will come from many sources. The most common sources for new requirements will often come from the below.
If you are starting a new project, you might be given a list of requirements that got created by your clients.
It’s also possible that you have been asked to help your clients define their requirements during an Ideation or Discovery phase. If you don’t know where to start with helping your client create an initial product backlog, you can read the following articles:
- Gathering & Defining Power Platform Requirements by Hamish Sheild: Where Hamish describes his framework to gather and define requirements using Observations, Journey Maps and Swimlane Process Diagrams.
- Value Stream Mapping – For your Dynamics 365 or Power Platform project: The Value Stream is the perfect tool to start building your initial list of requirements and create your Product Backlog. When creating the Value Stream, we identify the key actions that take place from the initial client interaction to the realization of value.
For inflight projects, new requirements will come from workshops, conversations and stakeholder feedback to demos or showcases.
If your system is already live, then new ideas will come from your end users currently working in the system.
No matter where your requirements will come from, it’s often a good idea to have a place to capture them so that you can do further analysis and determine their priority and feasibility.
Understanding the Product Backlog structure
The below diagram represents the requirement levels and their relationships that I use to structure my Product Backlog.
Epic:
Represent a high-level business initiative to be accomplished.
Feature:
Represent a Dynamics 365 or Power Platform feature or group of features that delivers on the Epic.
User Story:
A user story is an informal, natural language description of a single item of requirement.
Task:
A configuration or analysis task to be performed to deliver the User Story.
A typical product backlog would look like the example below. In this scenario, we have a fictitious Product Backlog for a university that wants to implement Dynamics 365 Customer Service to manage student enquiries.
Epics and Features
Epics and Features are useful to help you capture large long-term requirements. They will be too high level for a team to start work on, so I would typically stay at the level of Epics and Features only for requirements that will not be implemented in the next 3 months.
Epics and Features are also a great way to structure more detailed requirements. To find out more about how I structure my requirements using Epics and Features, read the my article about structuring requirements.
User Stories
For requirement details that will be implemented within the next 2 to 3 months, you need to go to the level of “User Stories”.
Remember that 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”.
So what are User Stories?
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 WHAT and the WHY of the requirement and not the HOW. Below is a comparison between how someone would write a requirement using a “system shall statement” including a HOW vs a “User Story” with a WHAT and a WHY.
A system-shall statement might say, “The system shall display key metrics of regional sales in a dashboard.”
The same requirement captured as a User Story might say, “As a sales manager, I can review all the key metrics for my region so that I can coach my team to pursue the best opportunities”.
Notice the key differences:
Three Traps to Avoid Working with User Stories and Power Platform or Dynamics 365 by Neil Benson
– The system-shall statement does not tell you who the story is for. The user story does. It is for a sales manager.
– The system-shall statement gives you a design constraint. The metrics will be displayed in a dashboard. The user story captures the requirement, not the solution.
– The system-shall statement doesn’t tell you why the requirement is valuable. The user story captures the value the sales manager will get from knowing the regional sales metrics. She’ll be able to coach her team more effectively.
A key concept about capturing requirements is to use the 3C:
- Card: Capture the User Story in Azure DevOps.
- Conversation: Make sure to discuss the User Story with your Product Owner and SME. You can capture the feedback and key discussions in the “Discussion” area the Azure DevOps User Story item.
- Confirmation: Add the Acceptance Criteria to your User Story to confirm the shared understanding and agreement of the User Story.
Anatomy of a User Story
Title: Short title for the requirement.
State: The State of the User Story. I often use at the minimum the following states: New, In Design, In Dev, In Unit Test, In UAT, In Prod (Done).
Description: Description of the User Story written in the format of “As a [Role], I want [Action]… so that [Benefit]”.
Documents: URL to a SharePoint folder where I can store additional documentation for the story like mapping tables or business rules if automation is required.
Acceptance Criteria: Additional details to help you confirm a shared understanding and agreement of the story. I usually limit my acceptance criteria to a list of maximum 10 bullet points.
Tags: I often use tags to help with filtering or categorization of User Stories. Below are some of the tags I previously used on my projects:
- Demo: To indicate that I want to demo or showcase the User Story to my Product Owner or SME.
- Review: Helps me quickly find stories that I need to review with my Product Owner or another team member.
- PO Review: The Story is ready to be reviewed by the Product Owner.
Story Points: Adding Story Points to your User Story helps estimate the amount of work required to complete the User Story. My friend Neil Benson has posted some great articles and podcasts covering how to estimates, when to estimates and what are the typical estimating units and scale. The following are some of Neil’s resources I recommend you take a look at.
- Estimating Dynamics 365 User Stories with Planning Poker by Neil Benson
- Estimating: how long and how much? by Neil Benson
Priority: Helps to make sure that high priority items get addressed first.
Related Work: You can link other work items to manage dependencies and see relationships:
- Parents: Helps you link the story to a parent Feature of Epic.
- Related: Each time you tag another story using the “#” hashtag, that item will be added to the Related section.
- Child: See the child tasks, test cases, etc. Nadeeja Bomiriya has written an insightful article where he explains the User Story Lifecycle and how a story evolves over time with the addition of Tasks and Test Cases.
More info on Microsoft Docs about how to Link user stories, issues, bugs and other work items.
Discussion: I use the discussion section to add comments and summarize discussions we have as the story evolves over time. Ex: SMEs and BA’s can propose additional Acceptance Criteria or ask clarification questions that I need to consider for the development of the story.
Tips for writing good User Stories
Writing good user stories is probably one of the hardest tasks the Product Owner will be responsible for. Below are some additional tips that you would want to consider when writing User Stories.
Decompose your Epic or Journey Map into a process flow where each step is a story.
The following article on Gathering & Defining Power Platform Requirements by Hamish Sheild describes how to use Journey Maps and Swimlane Diagrams as a starting point to write your User Stories.
Writing a User Story for each step in the process is about the right level of detail. Start from the first step and work your way through the process until the end. This ensures that you have user stories that cover the entire process from start to finish, and that you aren’t missing anything.
Hamish Sheild
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 you can consider combining them into 1 single story.
- Negotiable: Until the story is committed for work, it can be re-written, changed or cancelled at any time.
- Valuable: It delivers values 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.
- Testable: The story should have enough information to allow a tester to develop test cases.
Other References
- Should we have a standard set of user stories for Dynamics 365 projects? by Neil Benson
- How can we be sure we’ve captured all the requirements? by Neil Benson
- Microsoft Docs – Agile process work item types and workflow
What’s next
Below are some other topics I am planning to cover in future articles about how best to use Azure DevOps Boards for your Dynamics 365 or Power Platform projects.
Related or upcoming articles related to this series of articles:
- Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 1 – STRUCTURING REQUIREMENTS
- Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 2 – CAPTURING REQUIREMENTS (This article)
- Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 3 – REQUIREMENTS LIFE CYCLE
Let me know in the comment section below if there are any other topics, related to Azure DevOps Boards, that you would like me to write on.
If you would like to get notified when I publish a new article about Azure DevOps Boards, subscribe to my mailing list here.