Posts

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?

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.

Sometimes we can’t move forward with stories because it’s unclear whether our proposed approach will work. It’s time for a discovery spike! When we do a spike, we’re not aiming to have usable code or artifacts as a result of it. We’re merely doing the least amount of research and discover to be able to decide a general course of action. We might install some software, or write some code, to prove to us that it’s going to work. And then we might throw that code away. And when we work on the actual story, we product production quality code and artifacts. ...

It’s very important to store the stories in a way that they can very easily be merged and split. It’s common for teams to record too much information in their stories. To the point that it becomes very tedious and overly complicated to attempt to merge or split a story. And so it’s rarely suggested by the team, even though it’s the right thing to do. Merging is pretty straightforward to do. And splitting stories is more of a craft, because each story still needs to aim towards following INVEST. (Independent, Negotiable, Valuable, Estimatable, Small, and Testable.) ...