At the midpoint we check our team’s progress. If the team is behind, the worst choice is to tell them to “catch up.” More pressure makes builders rush, skip tests, and ignore edge cases. That leads to bugs, technical debt, and burnout. A better choice is to re‑scope. Ask: if the team keeps the same quality and pace, what can be finished this week? Remove lower‑value stories and set a new honest goal. ...
How do we choose what to build first? One approach to help figure this out, is to play a simple four-quadrant game: look at each story’s value and cost. Valuable and cheap: do it now. Valuable but expensive: do it later. Not valuable and cheap: maybe someday. Not valuable and expensive: don’t do it. This is just a guide to get the ball rolling, in some cases the results don’t always make sense. For example, Logout might be important and cheap, so do it; But Login may be important but costly, so wait; ...
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. ...