Beyond the Numbers: What 3 Years of Scrum Really Taught Me

After nearly three years of doing Scrum, I’ve learned a lot about managing projects, both within tech and beyond. But there are some things that I don’t personally do or find to be not as “important as they should be."

"Scrum Result Stats” such as Burndown Charts and Story Points

I’m actually fine if you want to use stats on sprints to measure how your team works and what their results look like. But my issue with this—and why I don’t use it as the main measurement—is because you cannot just use these numbers that are created out of thin air to measure how “good” your team works, the quality of output that’s released, or how each increment helps improve the product.

Another problem is that people become “fixed” to the points and numbers, which makes us ignore the “invisible member”—the team member who doesn’t give direct impact but is important to the team’s success.

I’ve seen organizations set point quotas—seniors must do 10 points, juniors do 5 points per sprint. The problem with this approach is that we forget seniors also need to do invisible work like mentoring juniors, reviewing codes, making architecture decisions and other important tasks. None of this shows up in story points. But it’s often the most valuable work happening.

When you focus on points, developers start chasing numbers instead of building useful features. The question shouldn’t be “How many points did you complete?” It should be “Did your work improve the product?”

Strict Sprint Commitment

The Scrum Guide does suggest that the Scrum team needs to commit to the increment they planned during sprint planning. But personally, I don’t think it’s necessary to complete all sprint commitments in the sense of “You must finish everything you said you’d do.”

Why? Because real development doesn’t work that way.

• Critical bugs appear mid-sprint
• You learn better solutions while building the product
• Stakeholder priorities change
• Team members get sick or blocked

Rigid sprint commitment creates “feature factories” where teams rush to build anything just to hit their numbers. It adds guilt to normal development challenges.

The Big Picture Matters More

The idea I want to emphasize here is to ensure that everyone on the team understands the big picture — the product vision and sprint goal, instead of thinking about reaching the “goals and numbers” set in the sprint.

When your team knows why they’re building something, they can:

• Make smart decisions when priorities shift
• Focus on valuable features over busy work
• Contribute important “invisible” work without guilt
• Adapt when they learn something new

It’s important that everyone understands the goal of the product and the sprint to ensure that the features built can become valuable and the product can keep improving increment-by-increment.

The Real Success Metric

The best sprints aren’t the ones where you hit every story point. They’re the ones where you moved closer to your product vision, learned something valuable, and maintained team quality.

Scrum is a great framework, but don’t let the tools become more important than the work. Focus on understanding over metrics, and adaptability over rigid rules.

Your users don’t care about your burndown chart or if you finish every items on your sprint—they care about whether your product solves their problems.