Treating Goals Like Sprints: An Agile Approach to 2026

January is a fascinating time of year. Coffee shops fill with people journaling their dreams, gym parking lots overflow with fresh determination, and social media buzzes with declarations of transformation. There’s something genuinely hopeful about it—this collective belief that a new calendar year means a clean slate, a chance to finally become the person we’ve been meaning to be.

But there’s a darker side to this optimism, one that the fitness tracking app Strava has quantified with almost uncomfortable precision. They call it “Quitter’s Day”—the second Friday in January, when statistically, motivation starts to crater and those ambitious resolutions begin their slow, quiet death. We just passed it a few days ago.

The numbers are brutally honest: research suggests that up to 80% of New Year’s goals don’t survive past February. Four out of five carefully crafted commitments, abandoned before winter even ends. Not exactly the inspiring success story we imagine when we’re planning our year on December 31st.

The Problem with Traditional Goal-Setting

I’ve been guilty of this pattern myself. Every January, I’d sit down with a notebook, feeling that familiar rush of possibility, and map out these grand, year-long commitments. Learn a new programming language. Read 50 books. Train for a marathon. Build three side projects. The goals themselves weren’t the problem—they were meaningful, challenging, aligned with who I wanted to become.

The problem was the approach.

Traditional goal-setting operates on this implicit assumption that we can predict, in January, exactly what we’ll need, want, or be capable of in June, September, or December. It treats the year as static when life is anything but. It demands perfect execution of a plan made with imperfect information, and when reality inevitably deviates from that plan, we’re left feeling like failures rather than recognizing that the plan itself might be flawed.

I spent 2025 learning this lesson the hard way. It was a transformative year—I started my Master’s at NYU, dove deep into computer vision and audio ML research, built projects I’m genuinely proud of, worked on meaningful research at IIIT-Hyderabad’s Cognitive Science Lab. I grew in ways I couldn’t have predicted. But many of my January 2025 goals? They didn’t survive contact with reality. Not because I lacked discipline, but because the person who set those goals in January couldn’t possibly know what the person in May or October would actually need.

Borrowing from Software Development

As someone who spends most of my time building ML systems and writing code, I’ve become intimately familiar with Agile methodology. It’s the dominant framework in software development for a reason: it acknowledges that requirements change, that perfect planning is impossible, and that the best path forward emerges through iteration, not prophecy.

The core principles are deceptively simple:

• Plan in short cycles (sprints), not long timelines
• Design based on current information and constraints
• Execute with focus and discipline within that limited scope
• Review what worked, what didn’t, and why
• Iterate based on those learnings

What makes this powerful isn’t the framework itself—it’s the underlying philosophy. Agile treats uncertainty not as a failure of planning, but as an inherent feature of complex work. It replaces the fantasy of perfect foresight with the reality of continuous adaptation.

So this year, I’m treating my goals like an Agile project.

What This Looks Like in Practice

Instead of setting rigid annual commitments and white-knuckling my way through them, I’m working in 3-4 week sprints. Each sprint has a clear theme, specific deliverables, and realistic constraints.

For example, my Q1 focus areas are:

• Technical depth: Diving deeper into audio ML and reinforcement learning
• Visibility: Being more active in sharing my work and connecting with the broader ML community
• Health foundations: Establishing sustainable routines for exercise and sleep

Within each sprint, I choose 2-3 concrete goals that ladder up to these broader themes. This week, that means:

• Finishing the implementation of a few-shot audio classification system
• Writing this blog post (meta, I know)
• Running three times and hitting my sleep targets

That’s it. No overwhelming laundry list of aspirations. Just a focused set of actions that I can actually execute on, given the reality of my schedule, energy levels, and competing priorities.

The Power of Retrospectives

Here’s where this approach fundamentally differs from traditional goal-setting: the retrospective.

In Agile development, every sprint ends with a retrospective—a dedicated time to examine what happened, why it happened, and what to do differently. It’s not a performance review or a blame session. It’s structured reflection designed to extract learnings.

At the end of each sprint, I ask myself:

• What actually got done? (Not what was planned, but what happened)
• What obstacles showed up? (Unexpected work? Energy crashes? Competing priorities?)
• What patterns am I noticing? (Am I consistently overcommitting? Underestimating certain types of tasks?)
• What should I keep doing? (What’s working that I want to maintain?)
• What should I change? (What’s clearly not serving me?)

This reframes “failure” entirely. A goal I don’t hit isn’t evidence of personal inadequacy—it’s data. Maybe I underestimated the complexity. Maybe the goal itself was misaligned with what I actually needed. Maybe external circumstances changed. The retrospective helps me understand which of these is true and adjust accordingly.

Compare this to the traditional approach, where you realize in December that you’ve missed most of your goals and spend the holidays either feeling terrible about yourself or making excuses. Neither is productive. Neither teaches you anything useful about how to do better.

Embracing Iteration Over Perfection

One of the hardest shifts in this approach has been letting go of the idea that my initial plan should be perfect. In January, I don’t know what challenges I’ll face in March. I don’t know what opportunities might emerge in May. I don’t know how my interests or priorities might evolve as I learn and grow.

And that’s okay.

The sprint model acknowledges that the best strategy is one that adapts. If I realize mid-quarter that my focus on audio ML is leading to exciting research opportunities, I can lean into that. If I discover that my initial approach to something isn’t working, I can pivot without feeling like I’ve failed.

This isn’t permission to be flaky or lack commitment. It’s the opposite—it’s being committed enough to the underlying vision that you’re willing to change tactics when the data suggests you should.

Building in Public

One specific goal I’m pursuing this quarter is being more active in sharing my work. This is actually harder for me than it might seem. I’m comfortable deep in the code, building systems, running experiments. I’m less comfortable putting myself and my work out there for public consumption.

But I’ve realized that visibility isn’t vanity—it’s strategic. The ML community is built on open collaboration and knowledge sharing. The best learning happens when you engage with other people’s ideas and let them engage with yours. Opportunities don’t find you when you’re invisible.

So I’m treating this like any other technical skill: something that can be practiced and improved. One blog post at a time. One project shared on GitHub. One conversation started. Each sprint, I’m setting a small, achievable target for this, and then reviewing what worked.

This post is part of that experiment.

What I’m Optimizing For

At the end of the day, this whole approach is about optimizing for sustainability over heroics.

I don’t want to be the person who crushes it for two months and then burns out. I don’t want to rely on willpower and motivation as my primary tools—they’re finite resources that run out precisely when you need them most. I want systems that work even when I’m tired, stressed, or dealing with unexpected challenges.

The sprint model gives me that. It builds in regular recovery time. It prevents me from overcommitting. It makes sure I’m regularly checking whether my actions align with my actual priorities, not just the priorities I thought I’d have months ago.

It also makes the whole endeavor more enjoyable. There’s something deeply satisfying about completing a sprint and seeing tangible progress. It creates momentum without the crushing weight of a year-long commitment looming over you.

Beyond Quitter’s Day

We’re now well past Quitter’s Day. The gyms are starting to empty again. The fresh notebooks are collecting dust. The ambitious declarations are fading into the background noise of another January.

But I’m still here, still working. Not because I have superhuman willpower or discipline, but because I’ve designed a system that doesn’t require it. The goals are manageable. The feedback loops are tight. The retrospectives are honest. And when something isn’t working, I can change it without feeling like I’ve failed.

That’s the real power of treating goals like sprints: you’re not locked into decisions made by a past version of yourself who had incomplete information. You’re building a practice of continuous improvement, where each iteration makes you slightly better at understanding what works for you.

So here’s to a year of quick iterations, honest feedback, and actually sustaining momentum beyond February. To building systems instead of relying on motivation. To treating our goals with the same rigor and flexibility we bring to our professional work.

And to making it past Quitter’s Day—not by sheer force of will, but by designing an approach that actually works.

This is the first of what I hope will be many reflections on process, progress, and the intersection of software thinking and personal development. If you’re experimenting with similar approaches or have thoughts on what works (or doesn’t), I’d love to hear about it.