Coach-Ram

What Is Agile Spillover? Spillover is when planned work (a product backlog item or story) is left unfinished at the end of the sprint or iteration and carries over to a subsequent sprint. Spillover in agile tends to occur for one of three reasons: Ambitious sprint goal, or Too much unplanned work, or Underestimating the effort required to complete the work. Occasional unfinished work is not a bad thing . In fact, it’s  normal and desirable to occasionally aim a little high in a sprint and  come up short. Too many spillovers, however, can reduce predictability, diminish creativity, harm morale, and threaten project timelines. Commitments Are Not Guarantees A sprint goal  is a commitment, not a guarantee. A commitment is a promise to try to achieve a goal. If forced to make a guarantee, a team will commit to less so that the guarantee is safe. Sometimes we do need to make guarantees, such as when a client or customer needs some capabili...

  1. Why Sprint Review ≠ Demo Sprint Review is a collaborative working session where the entire Scrum Team and stakeholders inspect the increment and adapt the Product Backlog. It's about outcomes, value, and strategic direction. The emotional tone here is collaborative curiosity and shared ownership . Demo is typically a one-way presentation showing that features work technically. It's more about proving functionality than exploring value. The emotional dynamic can sometimes feel like "us presenting to them" rather than "us working together." The key difference lies in the mindset: Reviews foster partnership and co-creation, while demos can inadvertently create a performer-audience dynamic that distances stakeholders from feeling true ownership. 2. How to Run Each Well Running a Great Sprint Review: Start with the "why" : Begin with business context and Sprint Goal, not features Make it interactive : Encourage stakeholders to actually use th...

What  i s   Product Backlog Refinement? Product backlog refinement—in the past was called backlog grooming since it includes keeping the product backlog clean and orderly.  Great refinement helps your team: Avoid surprises during sprint planning Reduce rework due to misunderstood stories Deliver value faster, with fewer blockers Refinement is when a team and its product owner look at the top items on the product backlog to make sure each is sufficiently well understood and small enough to be brought into the next sprint. That means breaking down large items, adding detail, estimating effort, and generally getting your stories “ready” for the team to work on. I like to hold the product backlog refinement meetings at the start of the current sprint to iron out any issues in the Sprint backlog and again about three days before the end of the current sprint. This gives the Product Owner   sufficient time to prioritize the backlog for the next Sprint.  Why Refin...

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...

I have delivered multiple training program and facilitated coaching interventions with Agile teams.  The most common discussion point is on the role of the Scrum Master. There is a lot of interpretations and hence confusion on this role. Let me try and provide some clarifications.   I will provide clarifications to 3 typical questions: 1. Who do Scrum Masters Report to? 2. How do I prove my value as a Scrum Master? 3. How do Scrum Masters encourage their team and other Stakeholders to follow Agile practices? 1. Who Do Scrum Masters Report To? Who should Scrum Masters report to is a tough question because so much depends on the Organization structure and the work being done by the Scrum team. Usually Scrum Masters will report into one of three places. A first option, which is common in product development teams, is to have Scrum Masters report into the product management group. However, this can sometimes lead to dysfunctional reporting paths such as the Scrum Master repor...

One of the most common questions asked by Scrum-Agile practitioners and the the question which also receives the most varied set of answers is this: What’s the difference between acceptance criteria and the Definition of Done (DoD) ? The simple answer is this: Acceptance criteria are specific to a   particular   product backlog item. Something becomes an acceptance criteria if it is so vital that the Product Owner will reject the item if it does not fulfill any of the criteria.   The Definition of Done, on the other hand, is  universal . A Definition of Done includes things that nearly all product backlog items need to comply with.   An Example Here’s an example of how I'm using a Definition of Done and Acceptance Criteria if I were to create a podcast on this topic.   The acceptance criteria for the podcast would be:   Explanation of Acceptance Criteria Explanation of Definition of Done Explanation of the difference between the two But for the podcast...

Story Points - An Introduction The scrum guide tells us that estimates should be provided by people that will be doing the work but it doesn’t tell us how we should provide estimates. It leaves that decision to us. A common tactic used by scrum teams is to estimate using a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time? Are we deliberately trying to obfuscate?   What is a Story Point? “ A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements “ Why use Story Points? Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only  how much effort a product backlog item will require, relative to other product backlog items . Ok, so it makes estimating easier but how is that useful? Story Po...

Estimation, the very word in itself seems quite heavy, and it does feel substantial when you are asked to estimate unfamiliar items to some degree. One of the key advantages of  adoption Agile is the capability of the team to estimate work effectually. Earlier when the teams were on waterfall, they used bottom-up approach with the smallest tasks at the bottom, in order to determine the cost of each feature. On the contrary, Agile uses two estimation techniques, such as Top-Down Estimation and Relative Sizing, since we are not concerned about the detail of the tasks. Instead, we are much more interested in swift estimates of higher-level features or even epics. What is Estimation? “Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.” As a part of the Scrum proc...