# Enterprise Brain Scrum MOM

## Context

- Meeting: Enterprise Brain Scrum
- Transcript date: Mar 18, 2026
- Transcript start: ~07:55 PDT
- Source: [eb-scrum-doc2.txt](eb-scrum-doc2.txt)
- Note: the transcript has an early interrupted fragment before the main discussion resumes around ~00:16:07.

## Act I - 00:16 to 00:25, capacity pressure and the discomfort of changing plans

After a noisy opener, the discussion settled into a candid talk about why the Enterprise Brain work had started to feel unstable. Yeshwanth named the core problem directly: the team keeps getting pulled into ad hoc changes and then has to re-explain the plan to everyone else. That is not a code problem yet; it is a planning and commitment problem.

> *"I feel bad that I'm confusing the team."*
> — Yeshwanth Reddy Yerraguntla _(~00:20:53)_

Gopal normalized the instability instead of treating it as failure. His view was that this project sits in a pre-sales and platform-shaping space, so roadmaps will continue to move as customer pressure and architecture insight evolve. The team should not read every plan change as a mistake; the real skill is deciding quickly, tightening the current scope, and then moving forward with the new shape.

## Act II - 00:25 to 00:48, demo timing should follow actual readiness

The next discussion focused on stakeholder confidence and what should count as a legitimate demo. Gopal advised against daily demos because they force premature proof and distort the engineering sequence. The team should show things when there is a real outcome, not because the calendar says to show something.

> *"Don't plan a demo on a daily basis."*
> — Gopal Gottumukkala _(~00:48:09)_

The group kept coming back to the same tradeoff: if a piece is small enough to demo in a day, it may still be too small to represent the actual problem. If it is too big, then the team needs to split it into a smaller working slice and keep the milestone date stable. That is why the meeting repeatedly came back to commitments, capacity, and how to protect the timeline while still adjusting the feature mix.

## Act III - 00:48 to 01:11, Jira history matters more than Jira ceremony

The most useful part of the meeting was the process discussion. Prabhakar made the case that delivery consistency comes from process, and Gopal pushed the same idea harder: code by itself is not enough if nobody can reconstruct the reasoning later. Jira comments, history, and traceability are part of delivery memory, not administrative overhead.

> *"Wrong usage of Jira is better than not using Jira."*
> — Yeshwanth Reddy Yerraguntla _(~01:30:07)_

That translated into concrete guidance. Summary should stay stable. Description should carry the main story. Comments should capture changes, rationale, and any evidence that the plan moved. If a task has to be re-scoped, the reason should be written in the ticket rather than silently edited out.

## Act IV - 01:11 to 01:31, lock the milestone, then bargain the scope

Gopal also warned the team not to make tasks bulky. Atomicity is not overhead in this context; it is the thing that makes planning and communication easier. The more a ticket bundles together, the more likely it is to confuse both engineering and leadership.

The meeting then moved into the hard rule on milestones. Milestone dates should not casually move; if capacity is tight, the team should remove lower-value work instead of moving the whole commitment. The milestone document should keep the deliverable shape visible, with the Jira link attached so leadership can inspect progress without needing repeated verbal check-ins.

## Act V - 01:31 to 01:40, close with a firmer delivery contract

The meeting closed with a calmer but stricter operating contract. From here on, the team should write more in Jira, keep tasks atomic, protect milestone dates, and use the ticket itself as the place where delivery memory lives. The transcript ends with that process discipline, not with a feature decision, which is consistent with the purpose of the meeting.

## Todos

<todo>
  Add meaningful Jira comments, rationale, and status history whenever tickets change rather than only moving statuses silently.<br/>
  <span class="owner">Entire Enterprise Brain developer team</span>
  <span class="deadline">Immediate, starting with current sprint work</span>
</todo>

<todo>
  Re-evaluate milestone deliverables with Prabhakar while keeping milestone dates fixed and only trimming scope when capacity changes.<br/>
  <span class="owner">Yeshwanth Reddy Yerraguntla / Satyasri Prabhakar Mantripragada</span>
  <span class="deadline">Next planning discussion</span>
</todo>

<todo>
  Create one shared milestone document that captures expected deliverables and stable Jira links for leadership review.<br/>
  <span class="owner">Yeshwanth Reddy Yerraguntla</span>
  <span class="deadline">Next communication-cycle update</span>
</todo>

<todo>
  Break bulky tasks into atomic Jira items before execution so the team can reason about scope and progress more clearly.<br/>
  <span class="owner">Team leads: Rajashekar G, Manisha Gundapuneedi, Yeshwanth Reddy Yerraguntla</span>
  <span class="deadline">Ongoing, beginning with upcoming sprint planning</span>
</todo>