---
title: "How Two Nights of After-Work Coding Cut Our Sprint Planning From Three Days to Half a Day"
url: https://daily.dev/posts/how-two-nights-of-after-work-coding-cut-our-sprint-planning-from-three-days-to-half-a-day-bncr87hqy
source_url: https://medium.com/@1128gigi01/how-two-nights-of-after-work-coding-cut-our-sprint-planning-from-three-days-to-half-a-day-c2213427b129
type: article
source: "Medium"
published: 2026-08-06T14:48:58.163Z
updated: 2026-08-06T14:50:31.905Z
tags: ["python", "agile", "product-management", "flask"]
reading_time: 4
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# How Two Nights of After-Work Coding Cut Our Sprint Planning From Three Days to Half a Day

**[Medium](https://daily.dev/sources/medium_js)** · 4 min read · 0 upvotes · 0 comments

## Summary

A product manager with a CS background built a simple Flask app called SprintFlow in two after-work nights to fix a chronic sprint planning bottleneck. The tool replaced error-prone Excel-based capacity planning with a shared backlog, per-person capacity bars, and filtered views per product owner. Sprint planning time dropped from three days to half a day, and the improvement held for six months. Key lessons: treat internal process pain as a product problem with real users and acceptance criteria, lead with personal benefit when driving tool adoption, and use existing skills to ship solutions without waiting for formal approval.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/@1128gigi01/how-two-nights-of-after-work-coding-cut-our-sprint-planning-from-three-days-to-half-a-day-c2213427b129>

## Questions this post answers

### What's a practical way to reduce sprint planning time when Excel-based capacity tracking is slowing down the team?

Replacing Excel with a purpose-built shared backlog tool can cut sprint planning from multiple days to half a day. A minimal viable version needs per-person task assignment with day estimates, visual capacity bars, split-sprint pipeline visibility, and filtered views per product owner. Writing a clear PRD before coding keeps the build focused and the outcome aligned to actual team needs.

_Teams still wrestling with planning overhead find the tradeoffs between lightweight tools and full-blown PM platforms covered on daily.dev._

## Similar posts on daily.dev

- [Dropping sprints: a year with Shape Up](https://daily.dev/posts/dropping-sprints-a-year-with-shape-up-0ifk4g7po) · Tech Lead Digest · 0 upvotes · 0 comments
- [What I Learned from a Quarter of Intentional Growth](https://daily.dev/posts/what-i-learned-from-a-quarter-of-intentional-growth-ajfjrccza) · Atomic Spin · 0 upvotes · 0 comments

---

Tags: [#python](https://daily.dev/tags/python), [#agile](https://daily.dev/tags/agile), [#product-management](https://daily.dev/tags/product-management), [#flask](https://daily.dev/tags/flask)

[View this post on daily.dev](https://daily.dev/posts/how-two-nights-of-after-work-coding-cut-our-sprint-planning-from-three-days-to-half-a-day-bncr87hqy)