Posts

The Iteration Planning Meeting should only take a few hours. The whole team can attend: (stakeholders, developers, testers, project managers, etc). Stakeholders (or their representatives) pick stories, generally in the order of business value. The team gives a best-guess number of story points they think they can finish building the story. The total story points for the iteration time window is the velocity. It’s important to note that velocity is a guess, not a promise. It helps the stakeholders choose how much work we can focus on during the iteration, but it isn’t a commitment. ...

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. ...

I once worked with a lead that insisted that every story card contain every detail. The cards were filled with tiny paragraphs and became impenetrable. They couldn’t be estimated, scheduled, or discarded because so much effort had been spent on each one. Stories are placeholders, not requirements. Write a short name and a few reminders, then save the real conversation for when you’re about to build the feature. Keep stories cheap so they can be split, merged, changed, or thrown away without regret. ...

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. ...

For big tasks I use trivariate estimates - three numbers: best‑case, nominal‑case, and worst‑case. Each number is a confidence estimate: Best‑case (5%): only 5% of similar tasks finish this fast. Nominal‑case (50%): about half the tasks finish by this time. Worst‑case (95%): 95% confidence the task finishes by this time. For example: “I’m 5% sure we’ll finish in 1 week, 50% sure in 2 weeks, and 95% sure in 3 weeks.” That means out of 100 similar tasks, ~5 finish in 1 week, ~50 in 2 weeks, and ~95 in 3 weeks. ...