User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

Ebin Poovathany has written a wonderful article on how we should focus more on the verbal conversation aspects of User Stories rather than focusing too much attention on “writing” User Stories. I myself have written an article about this as well (See Trap #’s 1, 8, 10,and 13). It’s great to see that this topic is starting to get more attention in the industry.

As Ebin points out, using so called “User Story Templates” (“As a user, I want..”, “In order to…I want…”, etc) causes people to backslide into older waterfall habits, and creating the same old kinds of documents that we used to create in waterfall, along with the same old problems. He said this is sad, and as a User Story proponent, I agree. It’s a horrible misunderstanding, but it’s rampant in our industry. The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth your five minutes to read Ebin’s article, and be sure to share it with your teams and organizations too!

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

I had the good fortune of being in a Q&A Session at Agile2012 with Ron Jeffries and Chet Hendrickson, early pioneers of Extreme Programming(XP), and both now Certified Scrum Trainers. Ron and Chet were sitting on the “expert couch” taking questions from the audience. I decided to break the ice by going on stage (questioners had to sit in the “therapy” chair next to the couch, and were time-boxed to 10 minutes) and asking them the first question of the Q&A session.

Keep in mind that this is just my recollection of the event. I’ll encourage anyone present to correct or add to what was said from their recollection. I lobbed them a softball of sorts. It wasn’t a hard question, but I wanted to hear their answer as Agile Manifesto authors. A friend in the biz had recently asked this question of me:

How do you interpret this Agile Manifesto principle?

“Simplicity–the art of maximizing the amount of work not done–is essential.”

I asked Ron and Chet to give some background on what that principle was meant to convey. Ron spoke from a programming perspective mostly. He said that simplicity refers to Kent Beck’s 4 rules of simple design. Kent’s definition stresses:

“…In priority order, the code must:

Run all the tests

Contain no duplicate code

Express all the ideas the author wants to express

Minimize classes and methods…”

The above is copied from Ron’s article on Emergent Design. Ron added that simpler is often simpler than you think, and simpler is often smaller than you think. He mentioned the phrase “the simplest thing that could possibly work” as a reminder to keep design and code simple.

Chet then chimed in on the topic of slicing stories smaller. By slicing them smaller, we can de-prioritize smaller stories in a more surgical way, thus avoiding work that is not needed right now, and may be never needed. There are also other huge benefits to smaller stories in that they are easily digestible, and thus less work to understand and implement. Chet stressed that smaller is probably smaller than you think. I then chimed in and mentioned a concept I had read in one of the XP books. If all of the details of your user story won’t fit on a card, then you should use a *smaller* card so that your stories are sized smaller because you’re clearly making stories too large and probably need practice at making them smaller. Chet finished by mentioning that, while simple is simpler and smaller than you think, you should be constantly inspecting and adapting your “simplicity” optimum.