The list of meetings and link to describe it.
Daily stand-up meetings
The daily standup is the most common. The attendees include the Development Team and Scrum Master, and the team uses this time to discuss their progress on a project and identify any hurdles. They share what they accomplished yesterday, what they plan to finish today, how it aligns with the sprint, and the issues they’re facing. These discussions help ensure that everything is going according to plan.
https://www.workhuman.com/blog/agile-meetings/
What is important thing is to focus on the reporting the plan / blocker. Even if there is blocker in your userstory, these items should be discussed in the different meeting such as tech huddle. By doing this, team members can understand the situation of other userstories as overview. If the topic is going to deep dive, anyone, especially Scrum master, should suggest the topic is off topic and make it on the other meeting.
Tech huddle
These are all nothing but quick discussions amongst the team members to talk about design approaches, resolve technical blockers etc. They can also be used to do group code reviews and code walkthroughs.
https://shilpa-goley.medium.com/technical-huddles-3c28d5a82548
The different name is dev huddle, dev meeting, daily huddle.
Sprint Planning meetings
Think of the sprint planning as a whole-staff meeting for the project. The entire scrum team needs to be present so everyone is aware of the stakeholders, instructions, updates, and goals. During the meeting, the Product Owner presents the product sprint backlog. The latter can include feature improvements, bug fixes, and other updates. Once the team is presented with these items, they draft objectives or sprint goals. Once the goals are locked, the sprint begins.
https://www.workhuman.com/blog/agile-meetings/
Sprint review meetings
A sprint review meeting occurs so the team can tackle output from their previous sprint. Along with the development team, product owner, and scrum master, stakeholders are also present. The team will showcase their work to receive feedback throughout the sprint. This helps agile teams track progress and share notes.
https://www.workhuman.com/blog/agile-meetings/
This is also known as show case, dry run.
Sprint retrospective meetings
The sprint retrospective meeting occurs after the sprint review. It includes the agile team and is completed by the end of the sprint. In most scenarios, the Scrum Master leads this meeting to reflect on the product.
https://www.workhuman.com/blog/agile-meetings/
backlog grooming
Backlog grooming is a regular session where backlog items are discussed, reviewed, and prioritized by product managers, product owners, and the rest of the team. The primary goal of backlog grooming is to keep the backlog up-to-date and ensure that backlog items are prepared for upcoming sprints. Backlog grooming, referred to also as backlog management, backlog refinement, pre-planning, or story time
https://www.productboard.com/glossary/backlog-grooming/
Lean Coffee
Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.
Opnion
This topic is about Sprint Planning.
I understand that the userstory should have reasonably small so that we can complete in the Sprint. However, it makes me feel that just spliting the existing userstory into 2 or 3 points from 8 points just to make the part of userstory is done. Why don’t we just start the 8point userstory and record the effort and rollever when this Sprint is finishd? I feel that is just burden to split the already clear defined userstory.
Is it best practice to split or rollover?
While rolling over feels easier, splitting is the industry best practice for several reasons:
- Maintaining Flow (WIP): Large stories represent high Work-In-Progress. Splitting allows the team to deliver “Done” increments of value throughout the sprint rather than waiting until the very end.
- Improved Predictability: Velocity metrics are more stable when stories are small. An unfinished 8-point story results in 0 points for the sprint, making it look like the team did nothing, whereas finishing two 3-point slices shows clear progress.
- Earlier Integration & Feedback: Small stories mean smaller PRs/MRs. This leads to faster code reviews, fewer merge conflicts, and earlier bug detection.
- Risk Management: If a story is 8 points, a single blocker on day 9 kills the whole item. If it’s split, you isolate the blocker to a single 2-point slice while the other 6 points are safely “Done.”
Summary: If a story is truly “clearly defined,” splitting it should be a simple exercise in identifying logical milestones (e.g., API contract first, then logic, then UI). If it’s hard to split, it’s usually a sign that the story isn’t as clear as we think!
Splitting Techniques to try:
- Workflow Steps: Split by the steps a user takes.
- Operations: Split by CRUD (Create, Read, Update, Delete).
- Data Variations: Start with one data type, then add others.
- Business Rules: Implement the happy path first, then edge cases.
The “Dev vs. QA” Split Trap
When a story feels too big, teams are often tempted to split it into a “Dev Story” and a “QA Story.” Avoid this.
Splitting by discipline is a “horizontal split.” It creates a mini-waterfall where no value is actually delivered until the second story is finished. A story should be a “vertical slice”—including design, code, and testing.
If you can’t slice it vertically:
1. Use a Spike: If the story is big due to uncertainty, create a time-boxed “Spike” to research the solution first.
2. Simplify the UI/UX: Deliver the functionality with a basic UI in Sprint 1, and polish the interface in Sprint 2.
3. The “Happy Path” strategy: Build the core logic that works for 80% of users first. Handle the complex 20% (edge cases) in a follow-up story.
Crucial realization: If you can’t find a way to deliver a small piece of value, you might be looking at a Task, not a User Story. Stories are about what the user can do, tasks are about what the developer does.
Reference: The INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable).