ART OF SCRUM: Why Product Owners Want to Tell You Stories

Posted: December 12, 2007 in Art of Scrum
Tags: , , , , , , , , , ,

Originally published: Tuesday, 12/11/2007

Really good Product Owners always start Planning Scrums with something along the lines of “Once upon a time…” The reason behind this is that one of the least understood but most powerful concepts in Scrum methodology (along with the Squeaky Toy) is the Story. A Story, essentially, is a short description of the usefulness of a feature or product, including vital information such as who is going to use it, why they want it, and what it is supposed to do.

From this trite-sounding invention, you can deduce what is important to who in the Scrum process, the business value, the importance in the grand scheme of the entire project, potential use / test cases, and a whole host of other information within the bounds of a properly-formatted sticky note. Product Owners are the conduit to the customer, or Stakeholders, and as such, they are responsible for translating important pieces of the Product Backlog into Stories. Stories are a bite-sized translation of a feature or client request into terms that the Team can understand, cut up into Tasks, and agree to deliver at the end of the Sprint.

According to Mike Cohn, a properly formatted story is thus:

"As a <some role> I want <something> so that <some value / justification>"

This deceptively simple formula drives Product Owners crazy, because it forces them to get rid of all of the ballyhoo and explain the basic purpose of this feature to the Team. In response, the Team is able to meet the Product Owner halfway and start from the bottom to build a feature or product that the client really wants by describing a series of Tasks that will reach this goal — demonstrable and working — by the end of the Sprint.

Once the Story is told, the Product Owner, the ScrumMaster, and the Team complete the Story by negotiating an Agreement. The Story is usually the top half of the sticky note; the Agreement is the bottom half. In order for the Team to be successful, it must meet the requirements set forth in the Agreement. Agreements are usually a series of bullet points that describe what should be demonstrable to the client by the end of the Sprint.

To put this into perspective, here is a Story with an Agreement from Achieve’s history. Note that Achieve has exercised the First Rule of Scrum: if the rules don’t work for you, throw them out.

STORY:
“This Story allows [the site administrator] to deploy quiz question creation to site users while guiding them to provide these questions in the right format.”

AGREEMENT:
* Exactly four answer boxes, all required
* No title field for users
* No feedback per question
* Auto-generate title field based on taxonomy, question field, and an incremental random number (to prevent repeats in any possible case)
* administrative controls to enable / disable functionality
* show mockups for the way this feature would look to a user

With a Story defined with an Agreement, as long as the Sprint is a reasonable length of time for the Team to perform this work without impediments, there will be a happy ending!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s