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.

As a cafeteria employee, I can use an employee dashboard online and drill through a series of contextual dropdowns that ensure I am who I say I am, and ultimately know my schedule faster. 

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 . . . . “

You know what, I’m not even going to bother writing the rest of that one. If a story starts off with the user being the Product Owner, then the story is not being written with the needs of the end-user in mind. (And isn’t that why we are doing what we’re doing?).  A story that starts like that  is being written by a product owner who just wants to tell the team what he or she wants—that’s most definitely NOT a conversation. (O.K. The exception would be if we were working on an application that allows Product Owners to take a specific action within that application—e.g. Rally , Service Now, etc.).


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)


Now, bringing it all the way back to where we started with user stories, the conversation is the most important part.  Are people going to write perfect stories every time?  Heck no.  If a Product Owner or team member adds some suggested “solution” to the story, should they be tarred and feathered?  Absolutely not–IF–(and that’s in upper case and bold for a reason), that person is willing to have . . . you guessed it. . . a conversation.  This is where Scrum Agile teamwork really pulls it all together. 

  • 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.

–and the only way any of those things can happen is if everyone on the team understands the function of the user story and is ready to have a good User Story conversation.


Posts created 17

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top