---
title: What Ten Years of Two-Week Sprints Taught Me About Realistic Estimation
description: Ten years of running two-week sprints across agriculture, fintech, and edtech taught me that better estimates come from process, not talent.
image: https://nyeinchanaung.me/hubfs/34fa9900-20f0-4f17-ac47-7896865c7fac.jpg
---

[Skip to content](https://nyeinchanaung.me/resources/what-ten-years-of-two-week-sprints-taught-me-about-realistic-estimation#main-content)

[![Group 1](https://nyeinchanaung.me/hs-fs/hubfs/Group%201.png?width=100&height=122&name=Group%201.png "Group 1")](https://nyeinchanaung.me)

- [About](https://nyeinchanaung.me#about)
- [Services](https://nyeinchanaung.me#services)
- [Case Study](https://nyeinchanaung.me#cases)
- [Experience](https://nyeinchanaung.me#experience)
- [Community](https://nyeinchanaung.me#community)
- [Resources](https://nyeinchanaung.me/resources)

- [Contact](https://nyeinchanaung.me/contact)

This is a search field with an auto-suggest feature attached.

- There are no suggestions because the search field is empty.

# What Ten Years of Two-Week Sprints Taught Me About Realistic Estimation

by [Nyein Chan Aung](https://nyeinchanaung.me/resources/author/nyein-chan-aung) on September 8, 2026

[Digital Product](https://nyeinchanaung.me/resources/tag/digital-product) [sprint](https://nyeinchanaung.me/resources/tag/sprint) [Project Management](https://nyeinchanaung.me/resources/tag/project-management)

I've run roughly two hundred and fifty two-week sprints. That number surprised me when I actually sat down and counted it — from a scrum-master seat at 360ed in 2018, through years of product management at Village Link, to the loan and traceability platforms I still advise on today. Same rhythm, same ceremonies, wildly different domains: education apps, microfinance wallets, an agri-social platform that now serves 300,000+ farmers.

What didn't stay wildly different was how often my estimates were wrong. Not because the team was bad at guessing — because for a long time, we were guessing, and calling it estimation.

This is the honest version of what actually got our estimates closer to reality. No framework claims a permanent fix here; these are five habits that moved the needle for me, in the order I learned them the hard way.

 

## 1. Separate the known work from the unknown work — don't average them together

In 2021, we migrated roughly a hundred thousand user records from Htwet Toe's legacy system to a new platform. I scoped it the way I scoped everything else at the time: break it into tickets, estimate each ticket, sum the tickets. The total came out confident and wrong.

The problem wasn't the estimating technique. It was that "migrate the data" and "build the new onboarding form" don't carry the same kind of uncertainty, and averaging them into one backlog hid that. The onboarding form was well-understood work — we'd built a dozen forms before. The migration touched a system nobody on the current team had designed, with edge cases nobody had catalogued yet.

Now I split those two categories explicitly. Well-understood work gets a normal estimate. Anything touching unfamiliar systems, a first-time vendor integration, or code nobody currently on the team wrote gets a short, timeboxed investigation first — a spike, sized in hours, whose only deliverable is a real estimate for the work behind it. It feels slower up front. It's faster than re-estimating mid-sprint.

![sprint-2](https://nyeinchanaung.me/hs-fs/hubfs/sprint-2.jpg?width=416&height=208&name=sprint-2.jpg)

## 2. Let the person doing the work size the work

For longer than I'd like to admit, I sized tickets myself and handed them to developers as fully-formed assignments. It was efficient in the way that skipping a step is always efficient — right up until the actual hours came back nothing like the plan.

The fix was almost embarrassingly simple: ask. The developer who's going to write the code has context I don't — which library is fighting them lately, which part of the codebase is fragile, what "similar" ticket from last sprint actually took twice as long. Estimation improved measurably once sizing moved from something I did *to* the team to something I did *with* them.

## 3. A buffer is not padding — it's an honest number with a name

Early on, "padding an estimate" felt like something to be a little ashamed of, so I didn't do it consistently, and the estimates that needed it most usually didn't get it. What changed my mind was realizing there's a real difference between padding and buffering.

Padding is adding time you can't justify because you don't trust the number. A buffer is a named, sized allowance for a specific category of risk you can point to — waiting on a partner vendor's API, working with agricultural data collection that depends on field connectivity, or building against a spec that's still being negotiated with a client. On projects like the MMTW loan and POS system, where cash and in-kind loan logic had to be worked out with the partner as we went, an explicit 15–20% schedule buffer wasn't pessimism. It was the most accurate number on the page.

## 4. Track estimate versus actual, every single sprint, even when it's uncomfortable

For the first few years, we ran retros that talked about *what* got built and rarely about *how far off* we'd been in predicting it. Once I started keeping that number — estimated hours versus actual hours, every sprint, visible to the team — two things happened. First, the gap got smaller within about three sprints, mostly because visibility alone changes behavior. Second, patterns showed up that no single sprint would have revealed: certain types of tickets (anything touching offline sync, in our case) were consistently underestimated by a wide, predictable margin, which meant we could finally correct for it directly instead of hoping the next one would be different.

## 5. A quarter-long initiative needs a different kind of estimate than a sprint story

Somewhere around the point where I was managing multi-month engagements — the AWBA Force IQ field-monitoring platform, the multi-year MMTW loan system — I learned that trying to estimate an eight-month initiative in the same units as a two-week story just produces false precision. Nobody can size "build a field-force monitoring platform" in story points with a straight face.

What worked instead was estimating in two layers: a rough, range-based T-shirt estimate at the initiative level (small / medium / large, revisited every few sprints as scope firms up), and normal sprint-level estimation only for the slice of work that's actually been scoped in detail. Trying to make the whole eight months precise on day one wastes effort estimating things you don't understand yet — and quietly signals a confidence you don't have.

## The thing I'd tell myself ten years ago

None of this made estimation exact — it isn't supposed to be. What it did was turn estimation from a number I defended into a number the team trusted, which is a different and more useful thing. The habits above are less a system and more a record of where the guessing kept breaking and what we did instead.

If it's useful, I put together the actual template I use for this — a sprint backlog with built-in variance tracking, a capacity planner with a named buffer field, and an estimation-accuracy tracker that rolls up automatically from the other two. It's a working spreadsheet, not a mockup — download it below and adapt the categories to your own team.

 

[Download Sprint Template](https://nyeinchanaung.me/hubfs/sprint-estimation-capacity-planner.xlsx)

 

Spread the word:

### Leave a comment:

## Related Articles

[![PRDs Developers Actually Want to Read](https://nyeinchanaung.me/hubfs/blog/Gemini_Generated_Image_gs0kyqgs0kyqgs0k%20-%20Copy.jpg)](https://nyeinchanaung.me/resources/prds-developers-actually-want-to-read)

### [PRDs Developers Actually Want to Read](https://nyeinchanaung.me/resources/prds-developers-actually-want-to-read)

A few years ago I wrote a PRD for a rice traceability tool — ShweBo Trace, built at Village Link to...

by [Nyein Chan Aung](https://nyeinchanaung.me/resources/author/nyein-chan-aung)

[![](https://nyeinchanaung.me/hubfs/ht-cover.webp)](https://nyeinchanaung.me/resources/htwet-toe-case-study-agri-social-platform-nyein-chan-aung)

### [Htwet Toe Case Study - Agri-Social Platform](https://nyeinchanaung.me/resources/htwet-toe-case-study-agri-social-platform-nyein-chan-aung)

A mobile-first advisory platform helping agricultural communities in Myanmar increase yield and...

by [Nyein Chan Aung](https://nyeinchanaung.me/resources/author/nyein-chan-aung)

[![Training Burmese AI for Farmer](https://nyeinchanaung.me/hubfs/Burmese_Agricultural_AI_Technical_Pilot-cropped.png)](https://nyeinchanaung.me/resources/burmese-ai-chatbot-pilot-lessons)

### [Piloting a Burmese-Language AI Chatbot on Small Dataset](https://nyeinchanaung.me/resources/burmese-ai-chatbot-pilot-lessons)

*At a previous company, I managed the development of a pilot AI chatbot meant to help...*

by [Nyein Chan Aung](https://nyeinchanaung.me/resources/author/nyein-chan-aung)

## Footer | Nyein Chan Aung

[![](https://nyeinchanaung.me/hs-fs/hubfs/Group%201.png?width=100&height=122&name=Group%201.png)](https://nyeinchanaung.me)

### Home

- [About](https://nyeinchanaung.me#about)
- [Services](https://nyeinchanaung.me#services)
- [Case Study](https://nyeinchanaung.me#cases)
- [Experience](https://nyeinchanaung.me#experience)
- [Community](https://nyeinchanaung.me#community)
- [Resources](https://nyeinchanaung.me/resources)
- [Contact](https://nyeinchanaung.me/contact)

### Resources

- [Products](https://nyeinchanaung.me/resources/tag/digital-product)
- [Projects](https://nyeinchanaung.me/resources/tag/project-management)
- [Case Study](https://nyeinchanaung.me/tag/case-study)
- [Community](https://nyeinchanaung.me/tag/community)

### Social Media

- [UniHack](https://www.youtube.com/@unihackchallenge477)
- [LinkedIn](https://www.linkedin.com/in/nyeinchanaung/)

---

[![Absolut theme logo](https://nyeinchanaung.me/hs-fs/hubfs/raw_assets/public/@marketplace/Kohorta/Absolut/images/brand/absolut-logomark-nobg.png?width=30&height=122&name=absolut-logomark-nobg.png "Absolut theme logo")](https://nyeinchanaung.me)

 ©Copyright 2026. All rights reserved

- Privacy
- Terms
- About
- Contact
- Help

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Nyein Chan Aung",
    "url" : "https://nyeinchanaung.me/resources/author/nyein-chan-aung"
  },
  "dateModified" : "2026-10-28T09:03:54.583Z",
  "datePublished" : "2026-09-08T10:03:44.000Z",
  "headline" : "What Ten Years of Two-Week Sprints Taught Me About Realistic Estimation",
  "image" : [ "https://nyeinchanaung.me/hubfs/34fa9900-20f0-4f17-ac47-7896865c7fac.jpg" ],
  "mainEntityOfPage" : {
    "@id" : "https://nyeinchanaung.me/resources/what-ten-years-of-two-week-sprints-taught-me-about-realistic-estimation",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://nyeinchanaung.me/hubfs/Group%201.png"
    },
    "name" : "Nyein Chan Aung"
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Nyein Chan Aung",
    "url" : "https://nyeinchanaung.me"
  },
  "datePublished" : "",
  "description" : "Realistic Estimation Sprint Template",
  "headline" : "What Ten Years of Two-Week Sprints Taught Me About Realistic Estimation",
  "image" : "https://nyeinchanaung.me/hubfs/34fa9900-20f0-4f17-ac47-7896865c7fac.jpg",
  "mainEntityOfPage" : {
    "@id" : "https://nyeinchanaung.me/resources/what-ten-years-of-two-week-sprints-taught-me-about-realistic-estimation?hs_preview=kHDiPnhk-392835539651",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : ""
    },
    "name" : ""
  }
}
```