Browse all posts in this category
"We need a technical debt sprint." This phrase is spoken in hundreds of teams every quarter. What happens next: two weeks of refactoring without clear direction, whose value is impossible to communicate to management, and which doesn't fundamentally change the most painful problems.
How many times have you had a 1-on-1 where your manager opened Jira to review your current tickets? That meeting could have been an email, or a glance at the Kanban board. A 1-on-1 that looks like a status report is a wasted 1-on-1.
Your team has a Notion page with next quarter's plan. It was written last week. Three people added comments. Two reacted with an emoji. The plan hasn't changed. No decision has been made. That's async without guardrails: lots of activity, little resolution.
When is an epic done? The question should have a simple answer. In practice, in most teams, it triggers a long conversation. The epic grows, splits, reopens, migrates from sprint to sprint. That is not a Scrum implementation problem. It is a definition problem.
"Our velocity is 42 points per sprint." This sentence is spoken with pride in hundreds of planning meetings every week. What does it actually say? That the team is closing tickets at a consistent pace. What it does not say: whether those tickets create value, whether the estimates are realistic, whether the team is thriving.
How many times have you seen a release turn into a catch-all of half-finished features, last-minute fixes, and tickets migrated from three previous sprints? The release has lost its meaning because it is only used as a delivery container, not as a management tool.
"As a user, I want to be able to log in so that I can access my account." This ticket has been written millions of times. It describes nothing useful about what the developer needs to do. That is the central problem with the user story as a unit of work.
