Choose One "Done" Story, Over Two "Almost Dones"

As we approach the end of an iteration we need to decide which stories we’ll see to completion and which we’ll postpone or abandon, so we can reallocate our team’s efforts to finalize more work. We proactively make decisions to put-aside some “almost-done” stories so we can let others reach done status. Two half-done stories aren’t progress. We are explicit about which work we stop and why, and then refocus the team’s attention on finishing the chosen set of stories. This keeps momentum, reduces waste, and preserves quality. ...

2025 May 7

Complete Stories Rather Than Tasks

Focus on stories, not the tasks. It’s far better to finish 80% of your stories than to make every story 80% complete. Completed stories give usable feedback, expose assumptions, and reduce risk. Value comes from done stories, not a subset of tasks.

2025 May 2

Story Point Estimation

At the start of a project, we haven’t set a precedent baseline of how to estimate our stories. So at our initial estimation meetings we can pick one average story as our Golden Story and give it a number (say 3). And then we compare the other stories to it: simpler might be 1, harder might be 5 or 6. Story points measure relative effort, not hours. They should be roughly linear but stay fuzzy at first. Write the point estimation onto the story. And keep the story brief. Perhaps just a title and a few short notes. ...

2025 April 10

Story Points

Story points are a simple, relative way to size work. We don’t size purely in hours, instead we compare one story to another: is this smaller, about the same, or much larger? Pointing becomes more precise over time. The key is to establish a tight feedback loop. Early estimates are imprecise, and that’s OK. As we work through our iterations we continue to deliver, measure, and recalibrate our point sizing. And that quick adjust-and-learn cycle transforms vagueness into useful predictability. ...

2025 April 8

Why Teams Don't Split Huge Stories

A team creates a user story for a full calendar feature. The PO, BA, UX, and accessibility SME add pages of detail so developers have everything they need. When developers see the ticket, they know it’s far too big. It needs splitting—but rewriting all that detail feels time‑consuming, inconvenient, and no one volunteers to do it. So the team decides to work on the giant story as-is and “figure out the rest later.” ...

2025 February 6