Team 04 - 2026

From Vancouver to Lagos, Brussels to Tampa Bay, five countries and five time zones came together.

Wherever the team needed support, we stepped up, shared the work, and delivered.

Team Mentor & Product Owner

M. Carol Hoeke

Orlando, Florida, USA

M. Carole Hoeke-Friberg served as Mentor and Product Owner for Team 4, guiding participants through agile delivery, strategic planning, and quality assurance.

A seasoned technology leader, consultant, architect, and Agile coach, she combines technical expertise with strategic insight to bring clarity, structure, and continuous improvement to complex projects.

Project Manager

Dana Mena

Vancouver, BC, Canada

Dana Mena is an Ops Admin and IT Systems professional from Argentina with 15+ years as a Systems and Business Analyst. After six years working in different countries and roles, she realized you can leave IT, but IT never leaves you.

Today she uses technology to connect people and support mission-driven projects.

Business Analyst

Ayo Eyo

Tampa, Florida, USA

Business Analyst, Project Manager, and Certified Scrum Master with 10+ years of experience driving Agile delivery, requirements analysis, process improvement, and technology initiatives. Skilled at bridging business and technical teams, facilitating collaboration, and translating complex requirements into practical solutions that deliver measurable business value.

Untitled (25 x 11.249 in) (1920 x 1080 px) (1920 x 2000 px) (19).png

Business Analyst

Henry Narh

Toronto, Canada

Banking and finance transitioning to Business Analysis

Business Analyst

Manjushree Shivaraju

Business Analysis and Automation Professional with 6 years of experience in enterprise automation for procurement, finance, and sales. Expert in business process analysis, stakeholder collaboration, and process improvements, achieving up to 40% reduction in manual effort. Proficient in converting business needs into tech solutions and enhancing cross-functional collaboration. Currently enhancing skills in requirements management and SDLC practices.

Developer

Folorunso Paul Oluwadara

Lagos, Nigeria

Folorunso Paul Oluwadara is a software developer with over four years of experience building web applications with React, PHP, Node.js, JavaScript and Firebase. He holds a B.Sc. in Software Engineering and industry certifications, and serves as Head of IT at Living Streams Missions Network.

As Team 4’s Developer in SDLC 2026, he delivered a secure, offline-ready inventory system for a food bank.

User Interface & User Experience

Damaris Bodea

Brussels, Belgium

With a background in B2B commercial operations, I've built hands-on experience is stakeholder management, process analysis and cross-functional clients. Currently transitioning into business analysis, I bring a systems-oriented mindset and drive to translate complex operational needs into workable solutions. My goal is to grow into a full BA role in a structured, visionary and impact-driven environment.

Team Observer

Adeola Ajayi

Southgate, Michigan, USA

Adeola Ajayi is a Business Operations Analyst with an M.S. in Business Analytics from the University of Michigan-Dearborn.

Combining frontline clinical experience with expertise in healthcare operations, business analysis, process improvement, performance measurement, and responsible AI integration, she helps healthcare and community-care organizations improve efficiency, quality, compliance visibility, and decision-making.

Project
Non-Profit Food Bank Inventory System

Problem Statement

Project Deliverables - By the Project Manager

Project Manager: Dana Mena

Solution Statement

For FoodBank volunteers and staff, who need to track contributions, distributions, and expirations, the FoodBank Inventory Management System is a system that enables accuracy and consistency in tracking inventory with consistent reporting.

Unlike the use of multiple manual copies of inventory sheets it provides consistency in grouping and data collection helping the organization accurately manage and report community supported food collection and distribution.

Kanban (Agile)

Project Plan

Project Manager: Dana Mena

How the Team Used It

The Project Plan was written after Session 1, from the business case and after we met with the Product Owner. It served as our shared starting point.

Lessons Learned

Start with a plan, then keep adjusting it. Regular PM and PO check-ins kept the plan current as we learned more.
Open questions are a gift. Writing them down early gave us a ready agenda for the Product Owner and prevented rework later.
Review risks on a schedule. Reviewing the risk register at every session kept risks visible to the whole team.
Plan for the gaps. With two weeks between sessions, regular check-ins made the difference between steady progress and drift.
Live sessions are the most valuable way to work together. Not everyone on the team used the chat, so our live sessions were where questions got answered, decisions got made, and the team really connected.
Keep it simple and flexible. Roles were a starting point. When the work called for it, team members stepped in beyond their titles and the plan adapted.

1. Project Overview

1.1 Purpose of This Document

This Project Plan is the Project Manager's core deliverable, produced at Session 1 by interpreting the business case - before any elicitation with the Product Owner takes place. It follows a standard PMBOK-aligned structure (scope, schedule, cost, quality, resources, risk, communications, and stakeholders) so it can serve as a template for any project the team runs, in the workshop or otherwise.

1.2 Project Summary

The food bank currently manages inventory across multiple spreadsheet versions maintained by different volunteers and staff, leading to overwritten data, missing updates, and inconsistent expiration-date tracking. Staff lose significant time reconciling spreadsheets and preparing grant reports by hand.

This project delivers a Minimum Viable Product (MVP) inventory tracking system that gives the food bank a single source of truth for inventory, reliable expiration-date tracking, and fast, accurate reporting for grant administrators, reducing food waste and the time staff spend reconciling spreadsheets.

References: Team 4 - Business Case - Non Profit Food Bank Inventory

1.3 Business Objectives

Objective: Improve inventory accuracy by decreasing the variance between audit results and inventory records, while eliminating multiple/duplicate inventory count records.

Why it matters: Maintains compliance with grant reporting requirements; noncompliance threatens continued not-for-profit classification and future grant funding.

References: Team 4 - Business Objectives - Carol Hoeke (PO).docx

Supporting objectives (PM-drafted):

Eliminate spreadsheet version conflicts by giving volunteers and staff one shared inventory record.

Reduce food waste by making expiration dates visible and actionable before items expire.

Cut the time staff spends preparing grant reports from hours to minutes.

Dependencies (confirmed by PO):

Volunteers able to record event data.

Audit report completed within 24 hours prior to deployment.

Volunteers able to transfer manually collected event data into the system on behalf of non-technical volunteers.

1.4 Success Criteria

Note: each item below includes what it means and how we measure it, so everyone reads it the same way.

Inventory variance of less than 5% between Audit Inventory count and Master Inventory quantity

What this means: the "variance" is the gap between the physical Audit count and the system's Master record for the same item. How we'd measure it: compare Audit results against Master quantities after each audit cycle. Open question: the sample data shows some large mismatches between Audit and Master for the same item — this may partly reflect a unit-of-measure difference (see Section 10.4, items 10–11) that needs resolving before this metric is fully reliable.

95% expiration-date compliance within 4 months

What this means: 95% of items in the system have a valid expiration date entered in the standard format — about data completeness and accuracy, not how much food actually expires. Example: if 500 items are logged, at least 475 need a correctly formatted expiration date attached.

Grant-ready reports produced in under 15 minutes within 4 months

A staff member can generate a report suitable for grant applications or audits. Example: items distributed by month, donations received, inventory on hand in under 10 minutes, instead of the hours it currently takes pulling data from multiple spreadsheets.

50% reduction in food waste from expired inventory within 6 months

Measured by comparing the amount (pounds or units) of food thrown away specifically because it expired, before vs. after launch. Example: if the food bank currently discards roughly 200 lbs./month of expired food, the goal is to get that down to about 100 lbs./month.

90% of volunteers rate the system "easy" or "very easy" within 90 days

Measured with a short survey after volunteers use the system (e.g., a 5-point scale from "very hard" to "very easy"). At least 90% of respondents need to select one of the top two options.

Single Master Inventory record (item & expiration date)

What this means: one system of record replaces the multiple/duplicate spreadsheet copies currently in use — this is the headline outcome behind the variance target above.

2. Scope Statement

2.1 In Scope

(document continues...)

Project Timeline

Value to the Team

The Project Timeline is a visual schedule that organizes the project’s phases, milestones, and key dates, from planning and initiation through to the Final Executive Demo on November 7. It was maintained in Miro as a visual reference, and documented in more detail in the Project Plan. Each week, the Project Manager used it to review with the team where the project stood and what needed to be completed over the following one to two weeks.

Lessons Learned: Structure with Flexibility

Pairing a visual timeline with a written plan gave the team both the big picture and the detail behind it. Regular weekly reviews kept everyone aligned on near-term priorities and on the MVP Demo date.

Not every deliverable stayed on track, and that was expected. The timeline gave the team a structure, but we worked with it flexibly. When needed, we sped up work, re-ordered work items, and adjusted as we went. Treating the timeline as a guide rather than a fixed contract let the team keep learning, adapt to what was happening, and keep moving toward the demo.

Project timeline inside Project Plan (Scheduled Management bookmark)

Project Manager: Dana Mena

Miro Link: https://miro.com/app/board/uXjVJG8xZYw=/?share_link_id=438887436627

Dependency & Open Questions Tracker

Project Manager: Dana Mena

Value to the Team

The Dependency & Open Questions Tracker is a running list of anything that could block the backlog. It covers dependencies, which are things one deliverable needs before it can move forward, and open questions that only the Product Owner or someone outside the team could answer. Every item had an owner, a target date, and a status. The PM and Business Analysts kept it organized, and the whole team added to it. It also carried forward the open questions from the Project Plan, so each session started from where the last one ended.

Lessons Learned: Surface Blockers Early

Write it down when it comes up. Logging each question with an owner and a date kept the team from guessing when an answer was missing.
Open questions became decisions. Items like role-based access, negative balances, keeping Master and Audit as separate records, and offline use as a must-have were all settled through the tracker.
Keep it alive. The tracker was meant to grow, and updating it honestly each session kept it useful.

(document continues...)

Project Deliverables - By the Product Owner

Business Objectives

Product Owner: Carol Hoeke

Business Need Summary

Product Owner: Carol Hoeke

Project Deliverables - By the Business Analyst

Initial High-Level Assessment

Business Problem/Needs

The food bank currently relies on multiple spreadsheets to manage inventory, donations, and distributions. This creates inconsistent inventory records, missing or overwritten information, difficulties tracking expiration dates, and inefficient grant-reporting processes. Staff spend significant time reconciling data and preparing reports, increasing the risk of errors, food waste, and operational inefficiencies.

The food bank requires a reliable and centralized inventory management process that provides a single source of truth for inventory information. The organization needs improved inventory accuracy, reduced data inconsistencies, standardized expiration-date tracking, and efficient reporting capabilities to support daily operations and grant administration. The solution must be easy for volunteers with varying levels of digital literacy to use and must function effectively in environments with limited internet connectivity.

2. Stakeholders

3.High Level Requirement

The solution shall provide a centralized inventory system that serves as a single source of truth for all inventory.

The solution shall support inventory tracking, including inventory items, quantities, storage locations, and expiration information.

The solution shall support donation tracking and provide access to recorded donation information.

The solution shall support distribution tracking and reflect distribution activity in inventory information.

The solution shall support expiration-date tracking to help identify items approaching expiration and expired inventory.

The solution shall provide inventory and expiration reporting to the staff and leadership.

The solution shall provide grant-reporting information to the leadership/grant administration.

The solution shall support offline data entry and synchronization when internet connectivity is unavailable.

The solution shall provide a simple user interface for volunteers with varying levels of digital literacy.

Business Analyst: Manjushree Shivaraju

(document continues...)

Current State Assessment

1.Current Process Overview

Trigger

An inventory transaction occurs:

Food donation is received, or
Food is distributed from the food bank.

Process Steps

1. Volunteer or Staff receives donated food items

a. Volunteer identifies the item and expiration date

b. Volunteer updates the Inventory Master Spreadsheet to reflect the newly received inventory.

i. Records Donation Date, Item, and Expiration Date

ii. Updates inventory - Quantity for Item and Expiration Date

iii. Optionally Confirms storage location.

iv. Enters Notes (optional)

v. Records Donor Contact Information (optional)

c. Processes item expiration

i. Volunteer or Staff identifies inventory items that have reached or passed the expiration date

ii. Expiration information is recorded in the expiration spreadsheet

iii. Inventory quantities are updated to reflect the removal of expired items

iv. Storage location information is updated as needed (storage location is updated as discarded(optional))

v. Expired items are removed from inventory and discarded

2. Staff stores food donation

a. Staff stores the donated food in the designated storage location.

b. Staff update the Storage Location in the Inventory Master Spreadsheet.

c. Staff optionally update Notes with any relevant information about the stored item.

3. Staff/Volunteer distributes the food

a. Volunteer/staff member records the transaction details in the Distributions spreadsheet

i. Records Distribution Date, Item Name, Quantity

ii. Optionally updates Notes and Contact Information

iii. Program ID will be updated for distributions made to an organization/program and program ID is not required for individual or family distributions

b. The staff member/volunteer updates the Inventory Master spreadsheet to reflect the item quantity distributed by expiration date

i. Identifies the applicable inventory quantity based on the item's expiration date and updates the Inventory Master spreadsheet

c. If an item is identified as expired during the distribution process, the item details are updated in expiration spreadsheet and removed from available inventory

4. Inventory Audit

a. The staff perform inventory audits by physically counting inventory and recording results in the Inventory Audit spreadsheet.

i. Records Item Name, Quantity, Expiration, Storage Location, Audit Date

b. Staff review inventory expiration dates in the Expirations spreadsheet for items approaching expiration or requiring removal

i. Staff identify the expired item quantity.

ii. Updates the expiration spreadsheet records.

iii. Updates the Inventory Master quantity to remove the expired quantity.

iv. Optionally updates the Storage Location to Discard.

v. Removes/discards the expired food.

c. The staff compare audit results with Inventory Master records and manually reconcile discrepancies when differences are identified.

5. Reconciliation of Inventory Activity

a. Staff reconcile inventory information across the available spreadsheet records.

b. Staff compares donation, distribution, and inventory information to identify discrepancies.

c. Staff identifies missing updates, overwritten information, or inconsistencies between spreadsheet records.

d. Staff updates the applicable spreadsheet records to resolve identified discrepancies.

(document continues....)

Business Analyst: Manjushree Shivaraju

Requirements List

Business Analyst: Ayo Eyo,
Manjushree Shivaraju

(document continues....)

Acceptance Criteria

Business Analyst: Manjushree Shivaraju

(document continues....)

Project Deliverables - By the QA/Tester

Test Strategy

(document continues....)

QA/Tester: Dana Mena

Value to the Team

The Test Strategy is the master plan for how testing works on the project. It explains the types of testing, who performs them, what “pass” and “fail” mean, and how defects are tracked and fixed. Team 4 kept it deliberately basic and combined it directly with the Test Scenarios / Test Cases spreadsheet, which holds 187 test cases with an owner, priority, and expected result for each. Keeping everything in one place meant the whole team could understand it and work from it. Team members volunteered as testers and ran the cases against the approved requirements, with defects logged in the same workbook.

Lessons Learned: Keep It Simple and Together

Basic is better for a mixed team. A short strategy with clear steps in every test case let people with different backgrounds test the same way.
One workbook for everything. Having the strategy, test cases, results, and defect tracking in one place made progress easy to see.
Agree on “pass” and “fail” up front. Simple severity levels and entry and exit criteria kept the team aligned on what “done” means.
Team members can step into testing. Clear instructions and an even split of the work let volunteers test effectively.

Test Scenarios and Test Cases

QA/Tester: Dana Mena

Value to the Team

The Test Scenarios and Test Cases workbook is where the Test Strategy was put into practice. It is one spreadsheet containing 187 test cases, covering login and role access, logging a donation, recording a distribution, expiring items, audits, and reports. Each case lists clear steps, test data, priority, expected result, owner, and estimated effort, and links back to the requirement or user story it checks. The work was split by effort across three volunteer testers (Dana, Ayo, and Damaris). Results and defects were logged in the same workbook, and a Summary tab updated automatically with pass, fail, and not-run counts. Everything was kept basic so any team member could pick up a test case and run it.

Lessons Learned

Clear Steps, One PlaceWrite each test case so anyone can run it. Simple steps and expected results let team members from different roles test with no QA background.Keep everything in one workbook. Test cases, results, defects, and the summary together made progress easy to see.Link tests back to requirements. References to user stories and acceptance criteria showed what each test was checking.Testing finds gaps in requirements. Cases marked “TBC” showed where the expected behavior was never defined, so the team could ask the BA or Product Owner before running them.Not everything fits the timeline. Prioritizing High cases and deferring some lower-priority ones (such as device and power-loss scenarios) kept testing focused on the MVP.

(document continues....)

Food Bank Inventory: Manual Testing Guide

Value to the Team

The Testing Guide was an internal how-to written for Team 4’s testers. It was not a formal deliverable, but it supported the Test Strategy and the Test Cases workbook. It explained the app and its main flow, how to get started, and how to work through the test cases in order, each tester taking the cases assigned to them. The guide also included a simple bug report template (title, steps to reproduce, expected and actual behavior, device or browser, screenshot, and severity) with three filled-in examples, one each for Critical, Major, and Minor.

Lessons Learned: Make It Easy for Anyone to Test

A short guide helps a mixed team. Testers from different roles could start quickly without QA experience.
Examples teach faster than rules. The filled-in bug reports showed what a good report looks like and how to judge severity.
Label your test data. Using “TEST” in names kept real and test data apart.
Consistent bug reports save time. The same format every time gave the developer what was needed to reproduce and fix each issue.

Food Bank Inventory: Testing Guide

About the App

This app tracks the food bank’s inventory: what comes in, what goes out, and what is running low or expiring. It works on phone, tablet, or laptop.

The core flow is: Select Role → Log Donation/Record distribution → Track expiring and view expired items → Perform Audit → View dashboards and monthly reports → approves and exports reports

Getting Started

App URL: https://foodbankinventory-d0237.web.app

Staff login: username staff / password staff

Leadership login: username leadership / password leadership

NOTE from Developer :

Everything you enter is saved in the DB. Please use obviously fake names, such as “TEST Canned Beans”, so test data is easy to spot and clean up.

How to Use This Guide

Pick Assigned from column J. Work through the phases in order. Later phases use data you create earlier. Test as a real food bank volunteer would. If possible, try some phases on a phone and some on a laptop.

Team 4 - Test_Scenarios_Test_Cases - Dana Mena (PM & QA).xlsx

Bug Reporting

Log every bug with:

Title: Short, descriptive (e.g., "Invoice PDF missing ")

Steps to reproduce: Numbered steps someone else can follow

Expected behavior: What should happen

Actual behavior: What actually happens

Browser/device: e.g., Chrome 125 / macOS, Safari / iPhone 15

Screenshots or screen recordings: Attach where helpful

Severity suggestion: Critical (blocks workflow), Major (broken feature), Minor (cosmetic/polish)

Here’s a food bank version of the bug report format, with a filled-in example.

Bug Report Template

Title: Short, descriptive summary of the problem

Steps to reproduce: Numbered steps someone else can follow

Expected behavior: What should happen

Actual behavior: What actually happens

Device/browser: e.g., iPhone 14 / Safari, Windows laptop / Chrome

Screenshot: Attach if possible

Severity: Critical (blocks work), Major (feature broken), Minor (cosmetic)

Example 1: Major

Title: Stock count goes negative when giving out more than available

Steps to reproduce:

Add an item called “TEST Canned Beans” with quantity 5

Choose to decrease stock and enter 10

Save

Expected behavior: The app blocks the change and shows a message like “Not enough stock.”

Actual behavior: The app saves it and the quantity shows as -5.

Device/browser: Windows laptop / Chrome

Screenshot: Attached

Severity: Major

(document continues....)

QA/Tester: Dana Mena

Project Deliverables - By the UI/UX Designer

How it all fit together

I worked on the UI/UX design of the Tampa Bay Non-Profit Foodbank Inventory web application with no prior design background, using Figma, Miro and AI assistance (ChatGPT and Claude).

Requirements and Product Owner meetings → user flows → paper wireframes → Figma prototype → the developer’s web application → team QA.

User Flows

UI/UX: Damaris Bodea

How they were used:

I built the user flows from the project documents as they were released, from the requirements and Product Owner meetings to the user stories, acceptance criteria, developer notes and test cases, and linked each flow to the requirements it covered. They became the basis for the prototype and the wireframes in Figma.

Lessons learned:

The flows changed every time a new document arrived, so I learned to treat them as a working document rather than a finished deliverable. Linking each flow to its requirement numbers made it much easier to check what was covered and to spot conflicts early.

UF-001 - Log a Donation

Actor: Volunteer, Staff, or Leadership - reachable from the no-login Volunteer Home, or from the Staff/Leadership Home after login. Trigger: A donor arrives with one or more donation items.

1. Enter the flow from Volunteer Home (no login) or Staff/Leadership Home (after login) → Start Donation.

2. Donor Info (optional): a single form - Name, Phone, Email, all optional. If the donor doesn't need a receipt, skip the form and tap Continue. This creates the donation session's 6-character reference code; the donor's name (or "Anonymous" if left blank) shows at the top of every subsequent screen in this session.

3. Select Category - tap-to-select across the 17 confirmed categories. "Other" tile opens a screen with two boxes, "Enter category name" and "Enter item name," each its own box, plus Confirm.

4. Select Specific Item- tap-to-select. "Other" tile available here too.

5. Enter Expiration Date. 6. The system checks the date automatically: if it's in the past, show "Expired, do not add to stock. Set it aside in the expired area," with a required checkbox "I moved it to the expired area" before continuing. (this is system-detected)

7. Enter Quantity (numeric, greater than zero) shown for every item, including expired ones. Expired quantities are recorded but excluded from active stock.

8. Add Another Item? → Yes: loop back to step 3. No: continue.

9. Review and Edit Items - totals line: Quantity received / Quantity expired / Quantity added to stock. Edit or remove any row.

10. Submit.

11.Receipt shown on-screen as a formatted list, grouped by category, item, expiration date, and quantity, covering the whole donation. Option to save/print as PDF.

12. Confirmation - Master Updated, with the 6-character donor reference code and item count.

Success outcome: One donor visit is recorded as a single grouped transaction, possibly covering multiple items, reachable by any role. Master inventory is updated per item once the transaction is fully complete; a donor who wants one gets a formatted on-screen receipt they can save as a PDF; expired items are recorded and excluded from active stock without blocking the rest of the donation.

UF-002 - Review Expiring / Expired

Actor: Staff or Leadership.

Trigger: Automatic - system flags items nearing or past expiration.

(document continues...)

User Flow Diagram

UI/UX: Damaris Bodea

Prototype

How it was used:

I built the Figma prototype from the user flows and paper wireframes, updating it after each round of input. The developer coded the web application from it, the result looked exactly like the prototype, and the whole team then tested it together.

Lessons learned:

Because the developer followed the prototype so closely, it became the specification in practice. Every label, button and rule in it ended up in the product, so getting the details right mattered. The trickiest part was designing before all the acceptance criteria were available. The requirements and the Product Owner meetings gave me a general view, and once the acceptance criteria arrived I could picture the full solution and adjust the design.

What I learned most

The hardest part came at the very beginning: figuring out how to think like a UI/UX designer and what to actually do. After that, what I needed most was time to think and to review the requirements, the Product Owner’s story, the user stories and the acceptance criteria. AI helped me summarize those documents and see the whole picture, so I could imagine the solution. The biggest lesson is that you can act on what you have, whatever the bottlenecks, as long as you keep an understanding of what the Product Owner presents. That was my guideline throughout

Wireframes

How they were used:

My paper wireframes guided the prototype, while the Figma wireframes, made later from the same flows, were used only by the developer as a reference.

Lessons learned:

Paper sketches were the quickest way to get from flows to screens. Next time I would make the digital wireframes before the prototype, so the team can review the layout early.

UI/UX: Damaris Bodea

Project Deliverables - By the Developer

Application Walkthrough

Developer: Folorunso Paul Oluwadara

Impact of the SDLC Experience Workshop

Project Manager

Dana Mena

It was a short but meaningful hands-on experience that helped me refresh my skills, reconnect with the IT community, and regain confidence after some time away from the industry. It was a great reminder of how much I enjoy this work!