What We Weren’t Doing: Takeaways from Agile Training

A few years back, we had a two-day agile training. A lot of it wasn’t new, but it was a wake-up call. The big takeaway? We were skipping the fundamentals. Not advanced techniques—just the basics. And we were paying the price for it.

Here’s what stood out the most—things we weren’t doing at the time but should’ve been.

🧠 We weren’t actually planning sprints

Planning wasn’t really planning. We crammed it into an hour, sometimes less. That same hour included the retrospective. And if we had unrefined tickets? We’d rush through those too—right there on the spot. There was no time to discuss goals, understand the why, or evaluate the shape of the work. It was more of a handoff than a plan.

⏱ We weren’t planning based on time

This one deserves a spotlight. We were filling the sprint based on velocity—some guess at how many points we “should” complete. But velocity isn’t capacity.

What we should’ve done:

• Define how many hours the team actually had for the sprint.
• Break down stories into subtasks with time estimates.
• Add those up and see what realistically fits.
• Let the team commit—with consent, not consensus, and not with the EM or PM deciding for them.

The idea isn’t to micromanage time but to help the team make an informed, grounded commitment. That commitment should come from a shared understanding of the work, not a top-down list of demands.

🪜 We weren’t breaking stories into tasks

Even when we refined stories with the PM ahead of time, we weren’t breaking them down into actionable steps during planning. That meant no real discussion of effort, no clear next steps, and very little ownership.

The team should own this part. Stories come into planning already refined—but breaking them into tasks should be the team’s job. That’s how they build understanding and prepare to commit.

📊 We weren’t tracking estimated vs. actual effort

This one's simple. If you never look back and ask, “How close were we?” then you never get better at estimating. It’s like guessing blindly every time and hoping for the best.

🪝 We weren’t using zero-point stories

We either inflated small tasks to “fit” the point scale or ignored them altogether. Zero-point stories let us track the small stuff without distorting velocity. They belong on the board.

🐛 We weren’t separating bugs and reactive tickets

Everything went into the same swim lane—bugs, features, hotfixes. It blurred the picture. We couldn’t tell how much of our time was reactive versus planned. That made it harder to defend our velocity or improve our planning.

✂️ We weren’t cutting dependencies or delays

We accepted blockers as normal. We weren’t surfacing dependencies early or adjusting plans to avoid waiting on others. The training called that out—and rightfully so. It’s not just a planning issue; it’s a delivery problem.

🔧 We were creating refactor tickets

Refactoring was treated like a separate body of work—something we’d ticket and maybe schedule “someday.” But the training made it clear: refactoring should be constant. You do it while you work. If you need a ticket to justify it, you’re already behind.

📥 We didn’t have a ‘Ready for Review’ column

Work went straight from “In Progress” to “Done,” even when it was sitting in review purgatory. That gave a false sense of progress and made it hard to spot bottlenecks.

🛑 We had no WIP limits

Everyone had too much in flight. The board was full, but not much was finishing. Setting work-in-progress (WIP) limits would’ve helped us focus and finish more instead of spreading ourselves thin.

📝 We weren’t writing real user stories

Most tickets were either tech tasks or vague summaries. There wasn’t a clear user, need, or value. A good story centers around a real person and a real goal—not just a to-do list.

🏁 We weren’t focused on finishing

This one cuts across everything: we were too busy starting. Not enough finishing. Stories dragged. Reviews waited. Little got done cleanly. The training hit us with the reminder: stop starting, start finishing.

What’s Next (and Maybe Part 2)

Since that training, I’ve tried a handful of these changes—some stuck, some didn’t, and some evolved into something better than what the training even suggested. From moving to time-based planning, to giving the team more control during sprint breakdowns, to making our board actually reflect the state of work—these weren’t just process tweaks, they were cultural shifts.

I’ll save the details for another post. Part 2 will cover what I actually changed, how it played out, and where we landed. Because implementing agile isn’t about copying a checklist—it’s about making the process work for your team, in your context, with your constraints.

Stay tuned.