Skip to main content
Project Management

Agile for Freelancers: Running Sprints When You're a Team of One

4 min read

Running agile sprints solo isn't about tools—it's about systems that survive your worst 3 AM coding hours

freelancingproject managementAgileLaravelUAE tech

Last July, I was knee-deep in build #37 for a UAE real estate platform and burned out mid-sprint. No deadline pressure, no client breathing down my neck—it was just me, freezing at 3 AM over a Vue component because I'd messed up my own task prioritization. That's when I realized true one-person agility isn't about tools or fancy workflows. It's about making the same system work when you're juggling code, scope creep, and the human need to occasionally eat/nap/have a life.

What Even Is a Sprint When You're Flying Solo?

Conventional agile talks about daily standups, backlog grooming, velocity charts. But when you're the full stack, project manager, and client liason rolled into one, some ceremonies feel absurd. I tried doing a Zoom standup with myself once. Recorded it. Watched it back. Never again.

Instead, I redefined "sprint" as any timeboxed chunk that keeps me focused. Two weeks works best—any longer and I forget what the original requirements were. Any shorter and you're just working in frantic one-day bursts. My setup:

  • Monday sprint planning: 30 minutes max with a physical notepad. No Jira sprawl.
  • Friday retrospectives: 15 minutes with a coffee, scribbling what went sideways (Spoiler: usually GitHub Issues being my only task tracker)
  • Daily 10-minute check-ins at my desk: Not a video call, just vocalizing progress to my plant, Steve. Plant therapy works.

The Tools I Actually Use (No, Not Notion)

GitLab's milestone tracking is my backbone. I create a milestone per sprint, attach issues to it, and close them manually when done. Why not linear.app? Because I need zero cognitive load between coding and tracking. If I have to think about how to track progress, the system fails.

Time estimates? Brutally honest ones. "3 hours" becomes "6 hours" once you factor in client back-and-forth, DNS headaches, and sudden 3 AM Vue meltdowns. I've started doubling my first gut estimate for client quotes. UAE clients especially expect quick turnaround ("This is a simple app, right?"), but doubling the time buys breathing room without feeling like a scammer.

And for actual time tracking? The Pomodoro Technique, but only when solo. 25/5 intervals work until week 2 of a sprint when a client sends urgent "quick changes" via WhatsApp. Which brings us to...

When Sprints Explode (And They Will)

Last year, I was building a Laravel/Next.js limo booking system—Tawasul Limo—deadlined for Q3. Client signed off on the sprint plan for payment integrations. Then Ramadan hit. Not the month itself, but the knock-on effect: the client's internal approver disappeared for two weeks, and my 2-week sprint crawled to a halt mid-March.

Had to renegotiate the sprint twice. Lessons learned:

  • Never assume client availability aligns with your timeline in the GCC. Holy months and summer breaks eat your calendar.
  • Buffer days suck to sell, but necessary. I now add "2+ days" in project proposals for "client decision time". No pushback yet.
  • If you're solo, scope isolation is survival. The limo project's payment work stayed frozen while I pivoted to another client's React Native bug fixes. Context switching hell, but better than sitting idle.

After that mess, I started using sprint "checkpoints" every 3 days. Not a full standup, just a 5-minute review:

  • Did I complete the thing I said I would yesterday?
  • If not, is it a blocker or just a distraction?
  • Do I need to move this task to next sprint?

Prioritization Without a Product Owner

How do you groom a backlog when your product owner is also you? Painfully. I use this stupid-simple formula:

Urgency × Complexity = Task Priority

(Yes, I wrote it on my wall in Sharpie.)

Urgency = client's actual pain point (e.g., "users can't checkout" > "button hover effect wrong"). Complexity = hours + domain knowledge. If a task is both urgent and complex (like integrating Stripe in a React Native app with Expo SDK 54—cough Greeny Corner cough), it moves to week 1. Low urgency/complex tasks go to next sprint or the "nice-to-have" column where 70% of features die.

Language barriers make this harder here in the UAE. If a client replies in Arabic about a Laravel backend issue, I'll sometimes spend 2 hours translating and clarifying instead of coding. Factoring that in upfront is non-negotiable.

Closing Thoughts (No, Not "Final Thoughts")

If you're an agile one-person band, the system isn't the thing you copy from textbooks. It's the thing you beat into shape with your own blood, sweat, and 2 AM meltdowns. My sprints don't look like a Scrum-certified playbook. They're scrappy, flexible, and sometimes held together with duct tape. But they keep solo projects moving forward without me losing my mind.

Found some of these ideas useful? Say hi at sarahprofile.com/contact. I’m neck-deep in sprint #41 right now—probably fighting with Firebase again.


S

Sarah

Senior Full-Stack Developer & PMP-Certified Project Lead — Abu Dhabi, UAE

7+ years building web applications for UAE & GCC businesses. Specialising in Laravel, Next.js, and Arabic RTL development.

Work with Sarah