Posts

Stakeholders operate the system during the demo. When stakeholders click the buttons and run the flows themselves, the team sees real reactions and honest feedback. Stakeholder-driven demos remove the temptation that builder team might hide flaky features, and the team might discover gaps in the acceptance criteria, or might surface usability issues. This hands-on approach builds trust, teaches stakeholders the system, and gives the team clearer, actionable data to fix what matters. ...

Leveraging an agile approach to software development isn’t just about going faster. It’s about concrete, measurable progress. Reliable data matters. Completion is achieved when the acceptance tests pass. Then the story is considered done. Saying a story is “90% done” hides uncertainty and misleads planning. It doesn’t tell us what’s left, how risky the remainder is, or when the work will be releasable. For honest forecasting and useful velocity charts, we only record stories that have passed their acceptance tests. That keeps our metrics trustworthy and reduces false optimism. ...

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

We write acceptance tests right after the IPM (Iteration Planning Meeting). Each story should have one or more acceptance tests, and we use those tests to decide when a story is done. Writing acceptance tests early helps us think through the story. It often brings up new questions, highlights edge cases, and uncovers alternate flows or use cases we may not have considered during planning. The team can choose to start with acceptance tests for the stories we plan to work on first. Acceptance tests shouldn’t take long to write, and it’s normal to have them all in place by the middle of the iteration. ...

After planning, we let the builders pick the stories they will own. It’s important to avoid having the managers and leads assign the stories to individuals. Instead we let the team negotiate ownership amongst themselves and encourage pairing, mentoring, and sensible scoping decisions. Discussions for your team Are assignments discussed and negotiated, or imposed on individuals? Do we encourage pairing on stories, or do individuals take on stories alone?