--- date: 2026-04-22 meeting: Enterprise Brain Scrum (two sessions) sources: - Enterprise Brain Scrum - 2026_04_22 21_25 PDT - Notes by Gemini (1).txt # full transcript, session 1 - Enterprise Brain Scrum - 2026_04_22 23_11 PDT - Notes by Gemini.txt # full transcript, session 2 duration: session 1 ~82 min · session 2 ~14 min --- # Enterprise Brain Scrum — 22 Apr 2026 **Date:** 2026-04-22 | **Sessions:** 21:25 PDT (~82 min) + 23:11 PDT (~14 min) **Source:** Two full transcripts — combined into one MOM ## Participants **RG** — Rajashekar G Mannam **YR** — Yeshwanth Reddy Yerraguntla **SP** — Satyasri Prabhakar Mantripragada **PG** — Phawhan Saii Gajjalakonda --- ## Act I — Demo Review: NSL Salesforce Context (~21:25 – ~21:10) SP opened the session by describing the client's expectations for the NSL Salesforce demo. The client (Pratima and team) wanted the system to pick up updates through simple prompts, enabling non-technical users to fetch live business insights without requiring technical knowledge. SP described this as the "wow factor" for the customer segment: > *"For a general customer in a non-tech industry, that is the wow factor — and obviously business needs to be trained."* > — SP _(~00:02)_ SP shared a demo showing the NSL Salesforce context: a landing page displaying how sales reps, deals, and leads contribute to business targets as of the current date. Some names on the landing page were hardcoded static values, which SP flagged as a problem. **The real-time data requirement:** The client's expectation was unambiguous — if Dia or Kamill updated a sale status during or before a demo, Enterprise Brain should reflect that change immediately on the next query. Tech-savvy NSL stakeholders would be able to distinguish static from dynamic data: > *"They are also techies. They can figure out which is static data, which is random data. So if they ask a certain question and it is not reflecting, then we are kind of fooling them."* > — SP _(~00:06)_ **Action taken:** PG was assigned to develop an API and hook it up to the dashboard so data flows directly from the PostgreSQL database (which holds synced Salesforce data) rather than from static fixtures. --- ## Act II — Visualization Issues: Top 10 Leads and KPI Representation (~21:10 – ~21:15) A query for "top 10 leads in the pipeline" returned only 5 results. SP noted this as a window/pagination issue and a chart orientation problem — SP suggested the correct representation for ranked leads is a horizontal bar chart. The UI layer was supposed to be intelligent enough to select the right visual automatically based on data type, but the current output was inconsistent. SP highlighted the key KPI representation expectation: percentage-based metrics (e.g., 16%, 17%, 48%) should appear on a **100% scale** — bar or donut — rather than as raw text. The client had explicitly expected this for the demo. The "key highlights" section was also raised: these highlights may come from data or internet, but the client expected them to be represented **visually**, not as bullet text. --- ## Act III — Business Terminology Training (~21:15 – ~21:19) PG acknowledged that the system was confusing **leads** and **deals**, likely because both shared the same underlying entities in the database. The system treated pre-qualified leads the same as qualified deals. SP was direct about the training gap: > *"We should train it to understand what are those terminologies — what are leads, what are deals, MQL, TNTSQL, proposal, contract — and represent those appropriately. If somebody asks what is my MQL pipeline, it should be able to pull out only those that are in MQL state."* > — SP _(~00:18)_ PG confirmed the Salesforce data lived in a PostgreSQL database, not a direct Salesforce connection. The data was therefore always the latest from the DB. --- ## Act IV — Communication Friction: Demo Notification and Design Churn (~21:30 – ~21:33) YR arrived and raised a process complaint. He had not been aware of the demo until very late: > *"I would have taken it a little more seriously. I was not aware of it. Customer deadline — if I am very clear in JIRA when is what — anything, that was all I mean — that would have helped me to take it more seriously on Monday, Tuesday, and tomorrow."* > — YR _(~00:31)_ SP explained that Raj and Pan were expected to reach out to YR whenever stuck. YR acknowledged this had happened, but the volume of design changes — new designs arriving every two days — created a "whiplash" effect. YR was sympathetic to RG and PG given the pace: > *"Our mistake is maybe architectural — changes that we have to be ready with least amount of code — and that is something that we should have anticipated."* > — YR _(~00:33)_ YR noted the team was keeping pace with changes and, in that sense, doing well. The recommendation going forward was to involve **Rakkesh** (the designer) at every checkpoint rather than waiting for Pratima or Navana to weigh in. --- ## Act V — UI Issues: Resolution, Scroll, and Clickable Notes (~21:57 – ~21:22) Late in the first session, the group reviewed the UI on a full-resolution screen. Issues surfaced: - **Resolution / responsive design:** The UI was not responding correctly to different screen sizes. SP described this as "a regular argument — the customer expected it to be responsive." - **Scroll indication missing:** When content extends below the visible area, there is no visual cue that more content exists. SP: "I don't have any indication that there is something below to see." - **Clickable notes:** Every note on the canvas should be clickable. SP confirmed this feature had been requested but was not yet implemented. - **Salesforce transition not functional:** Navigating from the Salesforce section broke at one point. RG offered to jump on a call with Salesforce to address outstanding items. SP suggested the Salesforce section could use a donut for percentage values (e.g., 0.2% still warranted a donut, not just text). --- ## Act VI — Session 2 (23:11): Dashboard API Validation (~23:11 – ~23:14) A brief follow-up session with PG and SP focused on validating the dashboard's API integration. PG confirmed he had developed and integrated the necessary API. The open items were: 1. **Which KPIs were rendering from the API** vs still using static data. 2. **Whether the SQL generated for each KPI** was correct against the actual business definition. PG clarified that on page load a single API call would fetch all metrics (not one call per widget). Refreshing the page would re-call the API. Individual widget data was now real (not hardcoded). Some comments in the codebase were mistaken for content — PG explained these were inline documentation comments, not user-visible text. PG planned to deploy locally and validate before final sign-off. --- ## Todos - [ ] Develop and integrate API to feed Salesforce dashboard data from PostgreSQL (not static fixtures) | author: Phawhan Saii Gajjalakonda | deadline: 2026-04-22 (same day) - [ ] Validate SQL queries for each KPI against actual business definitions | author: Phawhan Saii Gajjalakonda | deadline: 2026-04-22 - [ ] Train system on business terminology: leads, deals, MQL, SQL (Sales Qualified Lead), proposal, contract — ensure each state maps to the correct DB entity | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Check API integration: verify all widgets render from API, not static data | author: Abhilash Adunuri | deadline: 2026-04-22 - [ ] Prepare NSL Salesforce demo narrative (story walk-through) | author: Sel | deadline: 2026-04-22 - [ ] Share Enterprise Brain application link and credentials with Sel | author: Rajashekar G | deadline: 2026-04-22 - [ ] Add scroll indicator when content extends below visible area | author: unspecified (UI team) | deadline: unspecified - [ ] Make all canvas notes clickable | author: unspecified (UI team) | deadline: unspecified - [ ] Fix responsive design / media queries for different screen resolutions | author: unspecified (UI team) | deadline: unspecified - [ ] Forward all past meeting recordings to Yeshwanth | author: Satyasri Prabhakar Mantripragada | deadline: unspecified - [ ] Involve Rakkesh at every UI checkpoint going forward (do not wait for Pratima or Navana) | author: Rajashekar G | deadline: ongoing