How much should you keep the code checked out, before the team kicks you out?

"Some developers keep their code checked out for a really long time... Like a day or so"
-- Craig Larman, lecturing on feature teams

From Jeff Atwood's blog, a similar argument.

Blogged with the Flock Browser

For a better format for User Stories

Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was:

• As a <customer role>
• I want <functionality>
• because <customer value explanation>.

Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly the most important thing we want to achieve with the User Story format is "focus on the customer", which for us means focus on the value that customer needs to achieve with the functionality we are developing. So the question is: why is the most important thing the last in the current used user story format?

When teaching User Stories I've started to teach a "thinking model" (credit to Pekka Usva for pushing me to do this). It goes like this: whenever you start writing a user story always, always start by writing the goal (because...) part first. Never, ever write the functionality (I want...) first.

That's why Karl's post clicked: it makes perfect sense to change the format of the User Story. Therefore I hereby join my (blog) voice to his and Liz's and suggest to the community: let's start writing User Stories with the following format:

• In order to <value to achieve>
• as a <customer role>
• I want <some functionality>

What do you think?