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.

Terminology: Definition of Done vs. Acceptance Criteria

I’ve seen many folks imply that

  • The Definition of Done(DoD) is defined per story(or per Product Baklog Item(PBI), if you will)

or said another way:

  • The Definition of Done is different for each story.

I don’t agree with this.

There is a subtle but important difference between the Definition of Done and Acceptance Criteria.  It is summarized as follows:

Definition of Done:

  • The term applies more to the product increment as a whole
  • In most cases, the term implies that the product increment is shippable
  • The term is defined in the Scrum Guide
  • Used as a way to communicate the following to the PO
    • Overall Software Quality
    • Whether the increment is shippable or not

Acceptance Criteria
(aka Acceptance Tests, Conditions of Satisfaction, in some cases “Test Cases,” etc)

  • The term applies to an individual PBI/Story
  • The Acceptance Criteria are different for each PBI/Story
  • Term is not defined in the Scrum Guide
  • Used as a way to communicate to all involved that the requirements for a particular PBI/story have been met

If you wanted to, I guess you could say that part of the Definition of Done for any Sprint is that each PBI/Story in the product increment meets that PBI’s specific acceptance criteria.

However, I don’t know if you could definitely say that the converse is also always true:  “Each PBI must also meet the Definition of Done.”  For instance, one could decide that these things be part of the Definition of Done, but not be part of the acceptance criteria for each individual PBI:

  • Performance Testing on the integrated product increment
  • Exploratory testing on the integrated product increment in a test environment
  • Exploratory testing in a Staging/Pre-production environment

My concern is with people using “Done” and “Definition of Done” like terminology to describe when a Story meets its acceptance criteria, or that somehow the DoD is different for every Story.  The DoD needs to be broadly applied to the increment as a whole, and should stay relatively constant.  Of course, as teams update their DoD(hopefully improving it!), things will change, but it shouldn’t be different for each Story.  Also, when the DoD changes, it is imperative that it be well communicated to all on the Scrum Team, and especially the PO.

If you want a term to describe when a Story meets its acceptance criteria, maybe “complete” or “accepted” are better terms than “done.”

%d bloggers like this: