Doing Agile vs. Being Agile: Why Your Sprints Are Stalling

In today’s modern software development environment, many companies are adopting Agile Scrum with the aim of improving efficiency and speed. However, an alarming reality is that even after “running Agile Scrum” for a year, many teams still face delayed sprints, a large backlog of unfinished work, and missed deadlines. This raises a big question: Is the problem inherent to Agile Scrum, or is it in how we are applying it?

Why are sprints still late despite using Agile Scrum?

Through discussions, many core issues have been revealed, showing that the cause lies not in the Scrum method itself, but in the way the team is “living” with it.

1. Plans fail due to lack of real data

• Gut-feel estimates with no dependency logic
  • Example: A task to “implement a new login feature” is estimated to take 2 days. In reality, this feature depends on integration with a third-party authentication system, which the dev team has not thoroughly researched. As a result, the task stretches to 5 days due to API issues and compatibility errors.
• No clear “Definition of Done” (DoD)
  • Example: A dev reports a task as “Done.” But “Done” here only means coding is complete — no unit testing, integration testing, or PM/QC review. When testing starts, numerous bugs appear, forcing the task to go through multiple reworks.
• Ignoring the cost of context switching
  • Example: A dev is focused on developing a complex feature but gets interrupted by a critical production bug. They pause their current work to fix the bug, then return to the feature. It takes significant time to “get back into flow,” causing delays in both tasks.

A plan without data, risk calculations, or clarity is just a wish list, not a real plan.

2. Sprint Planning is a formality, not a strategy

• No debate over effort estimates
  • Example: In planning, tasks are quickly skimmed through, assigned, and estimated without discussion or challenge. A dev assigned “optimize database query performance” feels the task is more complex than the lead’s 1-day estimate but doesn’t speak up for fear of being seen as slow. This results in overwork or delays.
• No distinction between task types
  • Example: A “research new caching solution” task is estimated the same way as a “fix UI display bug.” Research tasks carry more uncertainty and require exploration, so underestimation is common.
• No buffer for unexpected events
  • Example: The sprint plan is packed with tasks, but midway, two team members take sudden sick leave. Their tasks either go unhandled or are redistributed, breaking the plan.

Sprints are late not because work is slow, but because the plan was wrong from the start — and no one dared to say so.

3. Scrum in form, Waterfall in mindset

• Poorly groomed product backlog
  • Example: A backlog item “develop warehouse management system” is too large and vague to be done in one sprint. Without breaking it into specific user stories, devs don’t know where to start and can’t finish it.
• No task breakdown by actual workflow
  • Example: The “integrate online payment gateway” task is considered done after coding. But QA testing, code review, and staging deployment are also needed. If these aren’t accounted for in the plan, delays are inevitable.
• Management still imposing targets
  • Example: The team estimates they can finish 5 features, but management demands 7 due to “business goals.” This overload reduces quality and causes missed deadlines.

How to plan effective sprints that don’t fail

To fix delayed sprints, teams need to change their mindset and approach, turning Scrum from a “procedure” into a real strategy.

1. Commit and face reality

• Ask: Can we commit? If not, why? Is the task unclear, dependent on someone else, or lacking resources?
  • Example: In Sprint Planning, instead of staying silent, devs should raise concerns if a task is vague or the estimate unrealistic: “I think this needs more time for research/unit testing. Can we adjust the estimate?”

2. Ensure enough information before starting

Each task should have:

• Clear interface or flow: mockups, wireframes, user flows.
  • Example: Before coding the “shopping cart” feature, PM provides full UI designs, add/remove product flow, and total price calculation rules.
• Business rules and data details: formats, constraints, logic.
  • Example: For “apply discount code,” define rules for eligible products, minimum order amount (e.g., 200k), and max usage limits.
• Clear DoD: completed code, passed unit tests, integrated, QA tested, reviewed, and successfully deployed to staging.
• Clear reviewers/testers: specify who will review and test.

3. Account for non-Jira activities

Sprint plans should include time for:

• Production support: reserve 10–15% of dev time for urgent bug fixes.
• Unexpected meetings.
• Collaborative activities: document reviews, PM discussions, code reviews.

Failed sprint planning isn’t due to weak teams, but because the team is living in an illusion: thinking they’re doing Scrum but still following old habits.

A good sprint isn’t the one that finishes the most work, it’s the one that meets commitments. Good planning starts by facing reality, not just “decorating” Jira to look nice.

Final Thoughts

Late sprints aren’t a Scrum problem, they’re a planning and mindset problem. By improving clarity, communication, and adaptability, teams can meet commitments more consistently.

👉Discover more insights, case studies, and expert tips on our CodeComplete blog.