Browse all posts in this category
Linear and Sinra both use the word cycle. That is not a coincidence: both tools reject the classic Scrum vocabulary. But beyond that shared word, their respective scope diverges sharply.
Monday.com lets you build anything: that is its marketing strength and its practical weakness. A development team that adopts Monday.com spends its first weeks defining, by itself, what a dedicated tool offers by default.
Asana is an excellent task management tool, used by marketing, HR and operations teams as much as by product teams. That versatility comes at a cost when it comes to tracking precise software releases.
Spending half a day configuring Jira workflows before creating a single ticket: many small teams live this moment and wonder if the tool is really made for them. Here is what gets in the way and what to look for instead.
It's 2pm. You just entered deep focus mode. Your ticket is moving. Then: a meeting invite for ten minutes from now. 'Quick sync on topic X.' This meeting could have been a three-line message.
The ticket moves to "Done". Everyone moves on. Three weeks later, you discover the feature was never deployed to production, integration tests weren't updated, and nobody set up monitoring. It was done, really?
Your team delivers 40 story points per sprint. The backlog moves. Tickets get closed. And yet users have been waiting on features for six months. Something is wrong. The problem: you are measuring activity, not value delivery.
It is 9:30. The team is gathered. Each person in turn answers the three questions: 'What did I do yesterday, what am I doing today, what are my blockers.' Fifteen minutes later, everyone goes back to their screen without anything having changed. This daily accomplished nothing.
Your organization has implemented SAFe. You now have ARTs, PI Plannings, System Demos, and Inspect & Adapt workshops. Your organization is also slower, more meeting-heavy, and more frustrating for engineers than before. This is not a bug in your SAFe implementation. It is often a feature.
Estimation is often a shared fiction: developers give numbers they know are imprecise, management treats them as commitments, and when estimates are exceeded, everyone is surprised to be surprised. #NoEstimates says: let's stop the fiction. The question is: what do we replace it with?
"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.
