Scrum Master Musings 2021 User Stories, how to make them the best
So a colleague and I are currently running an Agile Community of Practice for Engie. We have done a Basics of Agile and we will be doing a stories and story map session next week. I wanted to talk about stories as a follow up to yesterday's top tip... I guess you could call this top tip number two. Anyone that has read the Scrum Guide knows that the description of a user story is "a reminder of a conversation OR a promise to have a conversation" this is a great description and I would not change it too much, however what happens when people cannot recall the conversation? What happens when people do not communicate clearly and a critical piece is missed in the requirements?
For clarity sake I believe you need more than a promise of a conversation or just a conversation. In our experience it is best to record the things that the PO/users require for the story to be accepted, the acceptance criteria. What this does is provides a clear definition for the developer as to when the story is done and what is out of scope for the story. For the end users it provides them an idea of what to expect when using the software, for those running tests against the code it provides the definition of what to test for.
There are several other things that make stories the best they can be, but I will cover that later in blogs.
Director, Software Engineering - SaaS Operations
4 年What I've learned is that acceptance criteria can change if given enough time. I prefer not to 'have the conversation' until the team has their hands dirty and are actually working on the feature. That is where the conversation can have the most value and the team has the most context. The other advantage of waiting until the last possible moment is that the knowledge will stay fresh and be implemented soon after the conversation. This also reduces the waste of context switching or trying to remember prior conversations. Be wary of the 'documentation' trap of writing acceptance criteria long before the work begins. When the story is picked up, people will assume the conversation already happened and not bother to have a new one.
TAM - Red Hat
4 年Hey Mike, hope you get well soon