User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

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.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

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!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Agile2012 Q&A – Ron Jeffries and Chet Hendrickson on Simplicity

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:

1. Run all the tests
2. Contain no duplicate code
3. Express all the ideas the author wants to express
4. 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.