Many ScrumMasters and Product Owners are constantly searching for the perfect User Story format. The “As a I want so that ” schema is widely used, but in many organisations it has become a standard to put way more preparation than that into the definition of the User Story's details in preparation of the Planning meeting.

In the teams I've worked with recently stories usually contain the “As a …” phrase, a number of explanations, a number of acceptance criteria, and some attachments as needed. I think it's fair to argue that this preparation, that sprung from the imagination of one or two people, constitutes some serious up-front design that has several severe consequences.

The obvious thing is that such stories are not based on the latest state of the project, because they have created, in all detail, before their previous sprint was finished and reviewed. This alone makes it just so much less likely that teams will find the best, most effective solution to a problem.

Perhaps a bit less obviously, such complete user stories will also put the developers (and everyone else not involved in writing them) at an unfair disadvantage for the negotiations of the story's details, possible alternatives, or variants. It is way more difficult to modify an exisiting solution proposal into the best one the group could come up with than developing that from scratch.

Continuous collaborative learning is one of the fundamental principles of Agile. We're trying hard to get rid of big up-front design because we believe that group decisions based on the most recent learnings and changes in the project's environment beat a single mastermind's plans every day. Let's do the same with small up-front design, for the same reason.

I therefore propose to strictly develop all User Stories collaboratively between the Development Team and the Product Owner. The PO's preparation of the Sprint Planning meeting (or separate estimation meeting) should consist in a pre-ordered list of “As a …” phrases. Everything else must be found as a group.