Before we start

This document is created as an example business case for Inspectorio, with the example of McDonald’s fast food supply chain. It is written with a certain amount of assumptions due to the limited resources of time and personal resources for the sake of the test. Those are listed below:

1. User interview results presented in this document are mock answers and do not represent the actual voices and thoughts of the users.
2. The problems and prioritization being made for the solutions is only based on the writer’s opinion, in practice, it needs actual user interviews.
3. The plan is defined for the ideal Scrum team size which is under 12 people.
4. Assumed that McDonald’s inspection team already has a platform called “McInspect”. And McInspect already has features for inspectors to input collected answers/data.
5. Note that the content of this document is not considered to be confidential. Any information that is required to be non-disclosable won’t be included.

Context

In the state of California, over 2000 franchise restaurants are operating under the brand of McDonald’s. All restaurants have to strictly adhere to the Food and Quality Standards that are provided by McDonald’s HQ. The McDonald’s quality assurance team consists of 30 persons who are in charge of conducting inspections at each of the restaurants. An inspector of the quality team will visit a restaurant unannounced once a month and will work through a checklist of questions. Depending on those answers, a restaurant might PASS or FAIL an inspection. A failed inspection results in penalty payments and in stricter & more frequent inspections for restaurants.

A SaaS platform with both a web and a mobile application is being developed. The McDonald’s Quality team uses the web application to plan and coordinate inspections, which then get executed via the mobile application at the restaurant. An analytic dashboard for the Leadership team of Quality Assurance at McDonald’s is one of the new projects included in the product. The dashboard should make the most relevant insights accessible in just one place. As a Product Owner of this application and the new analytic dashboard feature, I will work and address the following subjects in this document:

1. Product development approach
2. Epics and user stories
3. Evaluate product success

Product development approach

In this section, we’ll dive into 3 aspects of this product to gather ideas and requirements for this product.

1. Target user: Define the current processes and type of users that are involved, and defined the user of the analytic dashboard.
2. User interview: Understand user needs and painpoints within the current process.
3. Feature design: Mapping user demands in different steps along with suggestions.

Target user

As the current process is already ongoing within the Quality Assurance Team, the diagram below demonstrates how this process works:

From this process, we are having 4 types of users participate in this process:

1. McDonald’s HQ: Headquarter executives team who will provide the Quality Assurance team with a sufficient list of restaurants on periodical chunks (monthly, quarterly).
2. Quality Assurance Team: The leadership team who plans and coordinates team members in the inspection process, and reviews the data collected.
3. Inspector: Member of the Quality Assurance Team who will conduct the inspections at the restaurant.
4. Restaurant: Owners and members of the restaurant who will provide the answers to the Inspector.

In this process, the Quality Assurance leadership team will need to look at the data from all inspectors and restaurants and will be the main audience who will use the analytic dashboard in the McInspect platform.

User interview

With the defined type of users, who are the Quality Assurance (QA) leadership team members, it’s essential to understand the needs and the painpoints the user faces in the current process to build the right features. Below is the prepared list of questions along with the collected answers in the interview process.

Objectives	Questionnaire	Answer
Understand needs and user behaviors when using the analytic dashboard	What is the current process of analyzing report data before you have the analytic dashboard?	The current analyzing and reporting process goes through the following stages: 1. Aggregate data of all Inspector’s raw reports 2. Look at the overall performance 3. Deep dive into different dimensions 4. Making essential actions based on data
	What kind of difficulties do you currently have with the current reports?	– It’s taking a lot of time to collect all of the necessary data from all of the inspectors. – Repetitive aggregation work for every collected report by Inspectors.
	What kind of actions do you usually take when you have the data you need?	– I need to aggregate raw data into a list of defined metrics for analytic purposes – I need to export the collected raw or aggregated data for advanced analysis purposes. – Compare the data by failure types periods, inspectors, regions, or owners.
Preferences on the designs and features needed for the dashboard	What are the top 3-5 key metrics that you want to see on the dashboard?	– Compliance rates (Pass rate) – Inspected restaurants (To compare with the planned) – Critical failure rates – Inspection completion rate (Between planned inspection and completed inspections
	How do you usually look at the data? Angle or Dimension used?	– By time (daily, weekly, monthly) – By regions, owners, or inspectorsTypes of failure
	What types of visualization do you usually look at	– To see trends: Line and bar charts – To snapshot based on defined groups like region: Heat map  – Quickly see the overview performance: Scorecard
	What are some additional actions you usually do when having the data needed?	– Customize reports using different metrics and dimensions. – Alerts or insights that are automatically generated from the report would be nice. – Customize view of the data for other members of the team based on their role  (like analysts, inspectors)

Feature design

Based on the result of the interview, all of the needs and painpoints are consolidated into a product backbone with the proposed solution for the Analytic Dashboard feature. 

Product backbone	Needs/Painpoints	Suggested Solutions
Data Availability	Collect raw data from different inspectors	Create a dataset that has all inspection data
	Calculate metrics from the raw data	Create ready to use calculation logic for the most used and important metrics
Analyze data	See the snapshot overview data	Allow the user to view prebuilt aggregated reports for important metrics on an “Overview” tab of the dashboard.
	Analyze data at different granularity	Allow the users to view different data dimensions through different tabs – Types of failures – Regions – Inspectors(Franchise) – Owners
	Viewing data at different timeframe	Allow the user to adjust the timeframe of the displaying data
	In-depth analytics for a selected metric.	Allow the user to look into a secondary granularity for each of the dimensions
	Compare metrics based on different durations to see performance trend	Allow the user to compare metrics with a different timeframe
Taking action	Export data for advanced analytic needs	Allow the user to export data from the data table at different tabs
	Seeing automatic suggestions or alerts	Allow the user to get automatically generated actionable items from the reports.
	Get notification in case of urgency	Allow the user to get alerts via email/messaging channels based on selected metrics.
	Customize report easily	Allow the user to customize reports with drag-and-drop features.

Epics and User Stories

Based on the needs and suggested solutions of the product backbone we can come up with the following list of epics and user stories. The prioritization is done at the user stories level using MoSCoW techniques after reviewing with the Quality Assurance team

1. MUST HAVE: Items that needed to be in the first iteration, cover the basic but critical needs of the user in the Analytic dashboard.
2. SHOULD HAVE: Items that is useful to have but do not required for the first iteration.
3. NICE TO HAVE: Items that are desired but are not critical in the near future. These items can be done in the later iterations.
4. This document does not address lower priority items.

Epic 1: Data preparation

This epic is the foundation for the Analytic Dashboard as it collects necessary data and metrics

Task name	User stories	Task description (high level scope)	Prioritization
Create raw data set	As a Quality Assurance Leader, I want to see reports data from all inspectors, so that I can analyze all of them	Create logic to calculate/aggregate the necessary metrics such as Compliance rates, inspection completion rate, etc.	MUST HAVE
Create aggregation logic	As a Quality Assurance Leader, I want to see data aggregated into metrics, so that I can get the information I need from the data.	Create logic to calculate/aggregate the necessary metrics such as Compliance rates, inspection completion rate, etc.	MUST HAVE

Epic 2: Data visualization

This epic focuses on providing the visualization features from the prepared data

Task name	User stories	Task description (high level scope)	Prioritization
Create overview dashboard	As a Quality Assurance Leader, I want to see a high-level overview of key performance indicators (KPIs) for restaurant inspections, so I can quickly assess overall performance.	Create a tab “Overview” with below data: – Display top critical metrics (Compliance rates, Inspection completion rate, etc) – Display charts showing snapshots of different dimensions (for example: a heat map of critical failure rate by regions)	MUST HAVE
Create critical dimensions dashboard	As a Quality Assurance Leader, I want to view inspection data at different levels of detail, so I can identify areas needing attention and necessary actions.	Create the report tabs corresponding with the following dimensions – Inspectors – Types of failure – Regions – Owners Each tabs show the detailed aggregated metrics with trending charts and tables of the corresponding dimensions.	MUST HAVE
Configure data by timeframe	As a Quality Assurance Leader, I want to adjust the timeframe of the data displayed, so I can analyze trends over different periods.	In all tabs, allow the user to adjust the viewing timeframe at day level.	MUST HAVE
View data at a secondary level	As a Quality Assurance Leader, I want to drill down data in different dimension levels, so I can understand the root causes of specific issues.	In the dimensional report tabs, allow the user to add a secondary level of dimension in the table.	SHOULD HAVE
Compare data at different timeframe	As a Quality Assurance Leader, I want to compare inspection data across different time periods (e.g., current month vs. previous month), so I can track performance trends.	For every displaying report, allow the user to choose to show another layer of data at a selected timeframe.	SHOULD HAVE

Epic 3: Taking action

This epic will focus on items that allow users to take additional actions from the displaying data

Task name	User stories	Task description (high level scope)	Prioritization
Export data from dashboard	As a Quality Assurance Leader, I want to export data from the dashboard to external tools, so I can conduct further analysis if needed.	The user can export data tables in common formats (e.g., CSV, Excel).	MUST HAVE
Automated suggestions	As a Quality Assurance Leader, I want to receive automated suggestions or alerts based on critical inspection findings, so I can prioritize resources and address urgent issues.	Export data from the dashboard	NICE TO HAVE
Receive notification	As a Quality Assurance Leader, I want to receive notifications via email or messaging channels for critical alerts, so I am notified immediately of urgent issues.	In the settings of the dashboard, the user can choose to receive email or message notifications for critical alerts.	NICE TO HAVE
Customizing report	As a Quality Assurance Leader, I want to customize the dashboard by dragging and dropping report metrics and dimensions, so I can prioritize the information most important to me.	Add a new tab “Customize”. In this tab, the user can rearrange charts, tables, and other report elements on the dashboard according to their preferences.	SHOULD HAVE

Example Wireframe

Below is the example dashboard on the page Overview, with other tabs showing different granularity of data.

Evaluate product success

To assess the impact of the Analytic Dashboard, it’s necessary to assess the product at different aspects. This dashboard, with the purpose of providing a holistic view of the inspection operational process, allowing the user to identify areas for improvement and prioritize future development efforts. We’ll track a combination of business goals, user satisfaction, and usage metrics below:

1. High level business goal metrics: reduce critical food safety violations from X% to Y%. From the usage of the dashboard, the Quality Assurance should be able to become more effective in terms of taking action upon the violated cases, and by that reduce the critical food safety violation cases.
2. User Satisfaction: Schedule regular interviews with Quality Assurance Leaders to gather feedback on their experience using the dashboard. This provides valuable insights into their satisfaction, pain points, and suggestions for improvement.
3. Active Users: Track the number of Quality Assurance Leaders who are actively using the dashboard on a regular basis. High active user numbers indicate that the dashboard is valuable and engaging for its target audience.

Thanks for reading