DEV Community: Gásten Sauzande

The Ultimate Sprint Planning Agenda (Built for Remote Teams)

Gásten Sauzande — Sat, 18 Oct 2025 13:25:40 +0000

Sprint Planning is one of those meetings that can either set your team up for success…

…or eat two hours of everyone’s time with little to show for it.

After 100+ sprints, especially with remote teams, I landed on an agenda that keeps things tight, focused, and under 90 minutes.

Here it is 👇

Step 1: Align on Value (10–15 min)

Start by answering: “Why is this sprint valuable?”

Without a Sprint Goal, you’ll spend the next hour in random discussions.

Step 2: Select Work (30–40 min)

Review refined backlog items in Zenhub.

Check:

Is the definition of done clear?
Are estimates aligned?
Any dependencies to note?

Commit to just enough work that matches team capacity.
It's great for team morale to have a clean board at the end of the sprint instead of an endless list that is never over.
Remeber, you can always drag in new items if the sprint is done.

Step 3: Sketch the How (30–40 min)

The team decides how they’ll deliver.

Break larger items into smaller tasks if needed.

Don’t over-engineer — just enough clarity to start sprinting.

Step 4: Confirm & Close (5 min)

Restate:

Sprint Goal
Selected backlog items
Confidence level (quick 1–5 poll)

Timebox: 90 Minutes Max

For a 2-week sprint, 90 minutes is more than enough.

If planning takes longer, you probably need backlog refinement mid-sprint.

Wrapping Up 🎯

A clear agenda keeps Sprint Planning from dragging on.

Focus on value, select the right work, sketch the how, and confirm. Done.

💡 To make this easier, I created a Free Scrum Master Checklist that covers Sprint Planning, Dailies, and Retrospectives — so you always walk into meetings prepared.

👉 Download it here

What’s your team’s biggest pain in Sprint Planning? Drop it in the comments — I might add it to my next checklist 👇

Stop Chasing Velocity: What to Measure in Zenhub Instead

Gásten Sauzande — Mon, 29 Sep 2025 16:53:04 +0000

If you’ve ever been asked:

“Why isn’t the team’s velocity going up?”

…you know how frustrating that conversation can be.

Velocity gets treated like a scoreboard, when really it’s just one signal among many.

After running 100+ sprints, here’s why I stopped obsessing over velocity — and what I measure instead in Zenhub.

Why Velocity Misleads 🚦

Velocity is just the total points completed in a sprint.

But it says nothing about:

The quality of the increment
The amount of unplanned work handled
Team morale or burnout
Whether the work delivered was even valuable

Chasing velocity creates pressure to inflate estimates or cherry-pick easy tickets. That’s not agility — that’s gaming the system.

What to Measure Instead 📊

Here are 3 healthier metrics I track in Zenhub:

Cycle Time
- How long does it take for an issue to go from “In Progress” to “Done”?
- Shorter cycle time = healthier flow.
Work in Progress (WIP)
- How many issues are active at once?
- Too much WIP = context switching = slower delivery.
Sprint Goal Completion
- Did we meet the outcome we set at Sprint Planning?
- Even if velocity was “low,” the sprint was valuable if the goal was hit.

Wrapping Up 🎯

Velocity is a data point, not a target. If you want to really understand team health in Zenhub, look at cycle time, WIP, and sprint goal completion.

💡 I created a free Scrum Master Checklist that helps you keep retros, dailies, and sprint planning focused — so metrics actually reflect reality.

👉 Grab the Free Checklist

The Invisible Work Problem: Why Your Team Looks Slow (But Isn’t)

Gásten Sauzande — Tue, 23 Sep 2025 19:34:18 +0000

If you’ve ever looked at your Zenhub board at the end of a sprint and thought:

“Why does it look like the team barely did anything?”

You’re not alone.

And in most cases, it’s not that the team is slacking — it’s that invisible work is stealing the spotlight.

What Is Invisible Work?

Invisible work is any effort that doesn’t make it onto your board but still eats up time and energy:

Quick Slack requests that turn into an hour-long rabbit hole.
Bug fixes that never got logged as issues.
Helping another team debug their blocker.
Ad-hoc meetings, support calls, or “just five minutes” tasks.

None of this is bad — in fact, it’s often critical.

But when it’s not tracked, your velocity, burndown charts, and estimates look completely off.

Why It’s a Big Deal

Invisible work hurts your team in two major ways:

False estimates – Next sprint looks like you’re underperforming because you didn’t account for these extra tasks.
Morale drops – The team feels like they’re doing tons of work, but the board (and leadership) says otherwise.

That gap creates tension and makes it harder to plan realistically.

How to Make Invisible Work Visible in Zenhub

Here are three ways I’ve tackled this problem after 100+ sprints:

✅ Create an “Unplanned Work” pipeline

Whenever something comes in mid-sprint, log it here. At the retro, you can quantify how much unplanned work hits each sprint.

✅ Add a quick “Support & Interruptions” issue

For teams constantly pulled into Slack or meetings, create a recurring issue each sprint. Add estimates for the expected time sink.

✅ Retro tracking

Use your retro to ask: “What did we do this sprint that isn’t on the board?” Then log those tasks before you close.

A Better Way Forward

The truth is: invisible work will always exist.

But when you acknowledge it, track it, and bake it into planning, your team suddenly looks a lot more like reality.

Instead of being “slow,” you’re simply being honest about where time goes.

💡 To help with this, I put together a free Scrum Master Checklist you can use to track sprint planning, daily standups, and retros — so invisible work stops flying under the radar.

👉 Download the Free Checklist here

What’s the most common invisible work you see in your team? Drop it in the comments — I’d love to compare notes.

5 Mistakes Scrum Masters Make When Using Zenhub (and How to Avoid Them)

Gásten Sauzande — Tue, 16 Sep 2025 18:22:45 +0000

Zenhub is one of my favorite tools for Scrum teams — lightweight, integrated with GitHub, and simple to use.

But after facilitating 100+ sprints, I’ve noticed Scrum Masters often make the same mistakes when adopting it.

✨ FREE resource: Grab my Retrospective Checklist to start improving your team today.

Here are the 5 biggest ones I’ve seen (and how to avoid them). 👇

1. Treating Epics Like a Backlog Dump 📦

Epics are meant to give structure and connect work to goals. Too many Scrum Masters just throw everything into Epics with no clear theme.

Fix:

Keep Epics outcome-driven, not just “buckets of issues.” Align them with your Product Goal and Sprint Goals.
Epics should fit nicely into your roadmap. Optimally your Product Owner creates and prioritizes the Epics and the team refines them into small issues for the sprint.

2. Overcomplicating Pipelines 🔀

Zenhub pipelines are simple by design. Creating a ton of extra pipelines just adds friction and confusion.

Fix:

Stick to 5–7 pipelines that reflect real states of work: To Do, In Progress, Review, Done (plus 1–2 extras if needed).

3. Ignoring Automation ⚙️

Zenhub has great automations — moving cards when PRs merge, closing issues when commits land, etc.

Many Scrum Masters don’t bother setting them up, so the board gets stale fast.

Fix:

Spend 30 minutes setting up key automations. It keeps the board alive without manual babysitting.

4. Using Reports as “Proof” Instead of Insight 📊

Velocity and burndowns are meant to spark conversations, not as weapons to push the team harder.

I’ve seen reports misused as “proof of productivity.”

Fix:

Use reports to facilitate dialogue: “What slowed us down here?” or “Why did we burn faster this sprint?”

It’s about learning, not policing.

5. Forgetting Action Items from Retros 🔁

Teams capture great insights in Retros — then forget them. Zenhub doesn’t enforce reminders, so action items fade away.

Fix:

Track retro action items as issues in Zenhub. Give them owners. Review them at the start of each Retro.

Wrapping Up 🎯

Zenhub is powerful, but only if you use it with the right mindset. Keep Epics meaningful, pipelines simple, automate the boring stuff, use reports for learning, and always follow through on retro actions.

💡 I put together a FREE Retrospective Checklist you can grab right now to start running smoother retros. And if you want to go further, I also built a Zenhub Agile Toolkit with ready-to-use checklists, guides, and templates — all based on lessons from 100+ sprints, in clean PDF format.

👉 Get the Free Checklist

What about you — have you run into any of these mistakes in Zenhub? Or others I didn’t list? Drop your thoughts in the comments 👇

Zenhub vs Jira: Why I Chose Zenhub After 100+ Sprints

Gásten Sauzande — Mon, 08 Sep 2025 09:42:17 +0000

If you’ve been a Scrum Master for a while, you’ve probably used Jira at some point. It’s the industry standard. But after using both and running over 100+ sprints, I prefer Zenhub all day everyday.

Here’s why 👇

Jira: The Heavyweight 🏋️

Jira is powerful, no doubt. You can customize everything: workflows, issue types, automations, integrations…

But here’s the catch:

Customization comes with complexity
Teams often need an admin just to manage workflows
It’s slower to get non-technical teammates onboard
And honestly? Jira fatigue is real — too many clicks, too many fields

If your organization is huge and needs strict reporting, Jira works. But for a lean Scrum team, it’s often overkill.

Zenhub: The Lightweight 🪶

Zenhub, on the other hand, sits inside GitHub. That’s the magic.

What I loved right away:

No extra tool: everything happens in GitHub (where devs already live)
Boards and Epics are simple, fast, and intuitive
Great for smaller to mid-sized teams who don’t want Jira’s overhead
Sprint Planning, Roadmaps, and Reporting are all built-in

It’s not as customizable as Jira — but that’s the point. The simplicity forces focus, especially for teams that use GitHub.

Why I Switched ⚡

After 100+ sprints the features we actually used could be done in Zenhub — without the bloat.

With Zenhub:

Planning was faster — backlog refinement felt lighter
The direct integration with GitHub issues meant that we had one source of truth
The reports are really good without drowning us in settings
The team spent less time updating tickets, more time shipping code

And for me as a Scrum Master? Less time configuring workflows, more time facilitating and coaching.

Should You Switch? 🤔

If your team is already deep in Jira, switching isn’t always realistic. But if:

You’re starting a new team
You’re already on GitHub
You want to reduce tool fatigue

…then Zenhub is absolutely worth trying.

Wrapping Up 🎯

Jira is powerful but heavy. Zenhub is lighter, faster, and — for many Scrum teams — more practical.

That’s why I chose Zenhub. It gave me back time, energy, and focus on what really matters: helping my team deliver.

💡 If you’re a Scrum Master using Zenhub, I built a Zenhub Agile Toolkit — including checklists, guides, and templates I’ve refined across 100+ sprints. It’s in PDF format, ready to use.

👉 Zenhub Agile Toolkit for Scrum Masters

What’s your take — are you Team Jira, Team Zenhub, or somewhere in between? Let me know in the comments 👇

The Only 3 Checklists You Need to Survive as a Scrum Master

Gásten Sauzande — Tue, 02 Sep 2025 18:20:08 +0000

Scrum Masters have a long list of responsibilities — from keeping meetings on track to ensuring the team continuously improves. But after running 100+ real-world sprints, I realized something:

👉 Most of the chaos can be handled if you keep things simple and consistent.

That’s where checklists come in. Instead of relying on memory (or 20 different templates), I boiled it all down to 3 essential checklists that make the difference between a smooth sprint and one that spirals out of control.

Here they are 👇

1. Sprint Planning Checklist 📝

Sprint Planning is where your sprint success (or failure) begins. Without structure, it’s easy for discussions to run long or lose focus.

Key items to check off:

Is the Product Backlog refined and prioritized?
Are dependencies identified before committing?
Does the team fully understand the Sprint Goal?
Are estimates aligned (Story Points, T-shirt sizes, etc.)?
Are capacity and availability taken into account?

When these are ticked off, you avoid the dreaded 3-hour planning sessions that lead nowhere.

2. Daily Scrum Checklist ⏱️

Stand-ups can become status updates instead of true collaboration. A quick checklist ensures they stay valuable.

Ask yourself:

Is everyone answering the 3 key questions (yesterday, today, blockers)?
Are discussions about blockers taken offline (not during the meeting)?
Is the meeting consistently under 15 minutes?
Does everyone leave knowing the next steps for the day?

Keep this tight, and you save hours of wasted team energy every week.

3. Retrospective Checklist 🔄

The Retro is where continuous improvement happens — but only if it’s structured.

Checklist for success:

Is there a clear structure or format (Start-Stop-Continue, 4Ls, etc.)?
Are last Sprint’s action items reviewed first?
Are new improvement items captured with owners?
Is there time reserved to reflect on the Retro itself?

With this, you avoid the “therapy session” trap and leave every Retro with concrete improvements.

Wrapping Up 🎯

You don’t need 20 different templates to survive as a Scrum Master. These 3 checklists — Planning, Daily, and Retro — cover most of the things you have to do. Stick to them, keep them visible, and refine them as your team grows(until you have to split).

💡 I put together a Zenhub Agile Toolkit with ready-to-use checklists (PDF format), templates, and guides based on my 100+ sprints of experience. If you’d like to save time and avoid reinventing the wheel, you can check it out here:

👉 Zenhub Agile Toolkit for Scrum Masters

What about you — do you use checklists in your Scrum ceremonies? Or do you run them without? I’d love to hear your take in the comments!

Why Most Sprint Plannings Run Over Time (and How I Fixed It in 100+ Sprints)

Gásten Sauzande — Wed, 20 Aug 2025 15:17:32 +0000

If you’ve ever sat through a Sprint Planning that dragged on for hours, you know the pain.

Teams get stuck in endless discussions, debates over estimates, or worse—planning the entire sprint down to the smallest detail.

After facilitating 100+ Sprint Plannings as a Scrum Master, I’ve seen these mistakes over and over. And I’ve also found a few reliable ways to keep things on track.

The Real Goal of Sprint Planning

Sprint Planning isn’t about solving every problem before the sprint starts. It’s about answering three core questions:

Why is this Sprint valuable?
What can be done this Sprint?
How will the chosen work get done?

If you’re doing anything more than that, you’re probably wasting time.

Why Sprint Plannings Go Off the Rails

Here are the most common pitfalls I’ve seen:

The backlog isn’t ready. The team wastes time trying to clarify vague items on the spot.
Too much detail. People dive into technical solutions before the sprint even starts.
Unclear Sprint Goal. Without a shared purpose, discussions scatter everywhere.
Overestimating capacity. Teams commit to too much, leading to longer debates and poor focus.
Silence in the room. Some voices dominate, while others check out completely.

Sound familiar?

How I Fixed It in My Teams

Here’s what consistently worked for me (and made Sprint Planning faster, smoother, and more useful):

1. Prepare like a coach, not a boss

I always synced with the Product Owner before the meeting to check:

Is the backlog refined?
Are the top items clear, with acceptance criteria?
Can we explain how this sprint will be valuable?
Is the priority of the tickets properly set?

If these weren’t ready, Sprint Planning was doomed before it began.

2. Set a Sprint Goal first

Before discussing specific items, I asked:

👉 “What would make this sprint valuable to stakeholders?”

Once the Sprint Goal was clear, choosing the right backlog items became easier and faster.

3. Use tools to keep focus

In Zenhub, I used Epics and pipelines to show progress and help the team pick the right items quickly.

No more scrolling through an endless backlog—just the items that mattered for this sprint.
Items that were ready to be picked up in the next sprint have a different column to all created tickets.

4. Close with confidence

We always ended by restating:

The Sprint Goal
The items we committed to
How confident the team felt (1–10 quick poll)

This alignment at the end saved us countless headaches mid-sprint.

If for some reason the confidence of the team is low, ask why and keep an eye on the time. A longer discussion might be needed which means that a different meeting should be scheduled, where more prep can be done.

My Checklist for Smooth Sprint Plannings

Here’s the short version I still use:

✅ Backlog refined before the meeting

✅ Sprint Goal agreed early

✅ Only discuss “how” at the right level (not designing the whole feature)

✅ End with alignment and confidence

Wrapping Up

Sprint Planning doesn’t have to feel like a marathon. With preparation, a clear goal, and strong facilitation, you can make it short, sharp, and effective.

I even built a full Zenhub Agile Toolkit with checklists like this (Retros, Dailies, Plannings) based on my 100+ sprints.

👉 Check it out here

Why Most Sprint Retros Fail — and the Checklist I Use Instead

Gásten Sauzande — Mon, 04 Aug 2025 17:59:38 +0000

From a Scrum Master who's facilitated 100+ Retros (and sat through some really bad ones)

Let’s be honest — Sprint Retros can get rough.
I’ve been a Scrum Master for a few years now, and after 100+ Sprints, I’ve seen all kinds of Retros: the good, the productive, and the ones where half the team looks like they’re mentally tabbed out, wondering what’s for lunch.

And to be fair, I’ve run some of those bad ones myself early on.

Here’s what I’ve learned — and the simple checklist I now use to keep every Retro grounded, relevant, and (dare I say?) actually helpful.

😬 Why Most Retros Fall Flat

It’s rarely because the facilitator didn’t try. Most often, it's because the team doesn’t feel like it matters. That’s the core issue.

Here are a few common reasons I’ve seen:

1. People tune out when the topics don’t feel relevant

This happens especially in cross-domain teams — when half the group is quietly thinking, “This doesn’t really involve me.”

2. It turns into venting... and nothing changes

I want my team to vent — it’s healthy. But if there’s no follow-through, people stop engaging. Why contribute if it just disappears into the void?

3. It doesn’t feel like a good use of time

This is the quiet killer. If people feel like they could be shipping work or prepping for another meeting instead, the Retro’s dead before it begins.

🧘‍♂️ How I Run Retros Now (And What Helped Most)

My style is pretty laid back — I treat Retros as a safe space. A break from the rush of the Sprint. It’s where the team can talk like humans, not Jira tickets.

But here’s the thing that made my Retros actually work over time:

I prepare. I take notes. I timebox. And I always follow up.

When I started taking the meeting seriously, the team did too.

I’d keep track of past action items. Remind the team mid-Sprint about what we said we’d improve. Bring data or context to spark real conversation. Keep the vibe low-stress — but never aimless.

🧰 The Checklist That Keeps Me on Track

Here’s the structure I stick to in nearly every Retro now — regardless of the format I use (I rotate through 4Ls, Start/Stop/Continue, etc. every month or so):

✅ Pre-Meeting

[ ] Block time on the calendar for everyone
[ ] Review last Sprint’s Retro outcomes — what did we say we’d improve?
[ ] Choose a format that fits the mood — or mix it up to keep it fresh
[ ] Gather quick data if relevant (burndown, incidents, bugs, etc.)

🧠 During the Meeting

[ ] Set the tone: “This is not a complaint session — it’s a problem-solving session”
[ ] Give space to vent, but keep it moving
[ ] Focus on what’s actionable — don’t get lost in abstract topics
[ ] Timebox each section so we don’t run out of steam at the end
[ ] Use the format as a tool, not a rule

🔁 After the Meeting

[ ] Write down the action items (somewhere visible)
[ ] Assign owners or volunteers
[ ] Remind the team mid-Sprint: “We said we’d try X — how’s that going?”
[ ] Bring results to the next Retro — close the loop

🎁 Want the Full Checklist (Free)?

I put together a clean, printable PDF version of this checklist — the same one I use with my teams now.

It includes pre-meeting prep, facilitation tips, and post-retro reminders.

👉 Download the free checklist here

✍️ Final Thought

If your Retros have been dragging, try making one small improvement. Maybe you prep a little more. Or rotate the format. Or just end five minutes early and give everyone a breather.

Over time, these little changes build a team culture that takes improvement seriously — and that’s where the real magic happens.

If you’ve had a Retro that totally bombed (we all have), or one that unexpectedly turned into a breakthrough, I’d love to hear about it. Drop it in the comments.

Let’s learn from the mess — and make better meetings.

A Practical Zenhub Guide for Scrum Masters (Based on 100+ Sprints)

Gásten Sauzande — Fri, 18 Jul 2025 21:59:16 +0000

If you're a new Scrum Master — or managing your own agile process with Zenhub — chances are you’ve thought:

“Wait… am I using this the right way?”

I’ve been a Scrum Master for over 4 years, and I’ve run 100+ Sprints across multiple teams. Zenhub is powerful, but without a clear setup and a lightweight process, it can get messy really fast.

If you’re running your first few Sprints in Zenhub, this guide will save you hours. I put together a guide based on 100+ Sprints — with checklists, templates, and real facilitation tips.

This post is a breakdown of how to use Zenhub effectively as a Scrum Master, with just the essentials:
✅ Clean workflows
✅ Epics that stay organized
✅ The right reports
✅ Fewer clicks, more clarity

Let’s jump in.

🧱 1. Set up a Workflow That Matches Reality

Your Zenhub Board is your team’s visual heartbeat. But most default boards include too many stages. I’ve found this simple setup works best for 95% of teams:

**To Do

In Progress

Review / Testing

Done**

💡 Optional: Add “Blocked” or “Ready for Review” if your team prefers more visibility.

Pro tip: Use Zenhub automations to move cards when PRs are opened/merged. It saves a ton of manual board wrangling.

🧩 2. Use Epics Strategically

Epics are great — until they become vague “buckets” that collect random issues.

How I use them:

Keep Epics goal-focused (e.g. “Improve onboarding experience” not “UI updates”)

Link only issues directly contributing to that goal

🔥 Bonus tip: Add an acceptance checklist inside the Epic description. It helps the team define “done” at a higher level.

🏷 3. Keep Issue Types Clear

Zenhub doesn’t enforce strict issue types — you define your own system. Use labels like:

story – user-facing work

bug – defects

task – tech debt or behind-the-scenes work

retro-action – improvement items from retros

spike – timeboxed research

✅ Label consistently
✅ Create GitHub issue templates to ensure that the team follows the agreed upon structure.

📈 4. Focus on These Reports

Zenhub has lots of reports, but for Scrum, I only check these regularly:

✅ Burndown Chart

Use it to guide mid-Sprint conversations

Don’t panic if you’re “behind” — look for patterns, not perfection

✅ Velocity Report

Great for planning future Sprints

Use average story points completed (not one-off spikes)

✅ Lead Time / Cycle Time

Helpful for spotting bottlenecks

If “In Progress” items sit too long, something’s stuck

🎁 Want the Full Toolkit?

I turned all of these insights into a lightweight, no-fluff toolkit called the Zenhub Agile Toolkit.

It includes:

✔ Checklists for Daily Scrum, Sprint Planning, and Retros
✔ A Zenhub setup guide
✔ People-focused coaching tips
✔ Templates and real meeting formats All based on real-world Scrum, not theory.

Here's a preview of what's inside:

You’ll get checklists like this for all the key Scrum meetings, plus Zenhub setup tips, and people-first facilitation advice.

👉 Want the full Zenhub Agile Toolkit?
Get the 3-part PDF bundle + templates here.

💬 Final Thoughts

Zenhub is one of the better tools for dev-focused teams — but it needs a little shaping. With the right workflow and just a few best practices, it can become your team’s most reliable dashboard.

Let me know in the comments:
What’s one thing you struggled with when setting up Zenhub or running your first Sprints? 👇