So What’s The Big Deal About User Stories? Part II

Applying Stories In Agile

From Part I of this series, we know the purpose that stories should serve. What’s next? Sometimes its easier to learn from mistakes, so let’s take a look at a couple of poorly written stories masquerading as good stories.

This example follows the formatting suggestions, but it is not inviting the conversation; indeed, it is solving the problem (badly I might add) and not clarifying what is really needed. It also uses a very subjective requirement–”faster.” Sure, a vague adverb like that will spawn conversation, but we need to have conversations about more important matters. A better version of this story might look like this:

As a cafeteria employee, I can find my schedule online so that I don’t have to wait until the next day to know when I am expected to be available for work.
 
Let’s 
try another one.
“As a Product Owner . . . . “

Let’s move on to the other half of the purpose of user stories— the acceptance criteria they help create. Specifically, I mean acceptance criteria that a well written story should engender. This discussion should take place in grooming of the story prior to sprint planning. Once groomed, (following some of the guidelines below), the story and the acceptance criteria should be more easily incorporated into Sprint planning if they have these characteristics.

• “They are not detailed requirements specifications (something a system shall do) but are rather negotiable expressions of intent (it needs to do something about like this) .
• They are short and easy to read, understandable to developers, stakeholders, and users .
• They represent small increments of valued functionality, that can be developed in a period of days to weeks .
• They are relatively easy to estimate, so effort to implement the functionality can be rapidly determined .
• They are not carried in large, unwieldy documents, but rather organized in lists that can be more easily arranged and re-arranged as new information is discovered .
• They are not detailed at the outset, but are elaborated on a just-in-time basis – thereby avoiding too-early specificity, delays in development, requirements inventory, and an overly-constrained statement of the solution.
• They need little or no maintenance and can be safely discarded after implementation.
• User stories, and the code that is created quickly thereafter, serve as inputs to documentation, which is then developed incrementally as well .”

(above list is excerpted from Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise By Dean Leffingwell with Pete Behrens)

• It is the job of the scrummaster to remind the writer of the story that including a “solution” can tend to anchor the conversation.
• It is the job of the scrummaster to coach the team towards fleshing out tangible requirements that will help size the story.
• It is the job of any member of the team to engage in meaningful debate about solutions that might influence the size of a story
• It is the job of every member of the team to call out if they think a written solution is painting the team into a corner.
• It is the job of the Product Owner (or anyone else writing user stories) to learn from mistakes and write more stories that focus on “why” and not on “how.”
• It is the job of the Product Owner to be available to answer questions the team has about the story’s requirements
• It is the job of the Product Owner to understand (and not have his or her feelings hurt) that a story can be rejected if the team says it is not comfortable pointing a story with only the current information available.
• It is the job of the team to clarify what information is still needed to assign points to a story–especially if the story is being pushed back.