ART OF SCRUM: Here’s a Little Story I Gots to Tell…

Posted: February 13, 2008 in Art of Scrum
Tags: , , , , , , , , ,

“…about three bad bullet points you may not know so well.”

# INVEST in the Creation of a Good Story:

Anyone who sits down to write a Story should not just dash something off to get the project / feature / defect / doohickey started because you want it now. Although Chris has mentioned the INVEST acronym before, it bears repeating.

* INDEPENDENT
* NEGOTIABLE
* VALUABLE
* ESTIMABLE
* SMALL
* TESTABLE

Nothing helps create a good Story like keeping it small. I have overheard discussions where people say that it is too small to make a Story out of it. I profoundly disagree — creation of the Story IS the Discovery phase of the Achieve Approach. Investment in a Story is more than the acronym itself; investment also means to put some critical thinking, time, and effort into writing a good Story. A Story in time saves nine, my friend.

# Good Stories are SMART:

SMART Stories also consider another clever acronym to keep Storytelling focused and to the point::

* SPECIFIC
* MEASURABLE
* ACHIEVABLE
* RELEVANT
* TIME-BOXED

One crucial concept in SMART is “Time-Boxed” — a fancy way of saying that the Sprint is a non-negotiable timed event. Time is one of the three sides of the Project Triangle (ding! ding! ding!) and is one of those things that is tweaked as a factor throughout project life cycles in order to make the other sides (Quality, Cost) look better to a Client. Time-boxing a Sprint stops moving the goalpost on this aspect of working, and it really makes a difference when you know that you must deliver working code by a fixed date.

# Well-designed Stories SELL:

Once upon a time (last week), with a Client far, far away (ok, up in LA), there was an IT Manager who was trying to explain what he wanted to do with his website budget. After several frustrating meetings with the holders of the purse-strings while bandying around phrases like “anonymous user caching performance tuning”, “multi-vertical expletive parsing modules”, and “discombobulation of dilithium crystal flux capacitor obfustication”, a certified Achieve Internet Product Owner wrote some Stories to explain what he was really wanting to do. These Stories had a formula:

### OVERVIEW:
[general summary goes in here]

### BUSINESS GOALS:
[business value / reasoning goes in here]

### BUSINESS LOGIC:
[logical flow goes in here]

### REQUIREMENTS:
* [bulleted list of “doneness” requirements / use test cases]
* xxx
* xxx

### QUESTIONS:
* [bulleted list of questions for PO to ask Client if needed]

### ASSUMPTIONS:
* [any assumptions being made by the Client or Achieve relating to this Story]

By following this formula (and attaching a quick table of phases with time estimates), the Product Owner followed the Achieve Approach and Scrum. However, this is normally an internal process; in this particular (and highly educational) case, providing the Stories to the Technical Contact at the business armed him with the ammunition needed to succinctly explain what he wanted to do with his budget! In short, writing Stories in this fashion sold the services because they were comprehensible to the Business Owners at the Client.

This is truly value-add for Project Management at Achieve, and I believe it is an eye-opener for our massive and talented Sales and Marketing divisions. Writing good Stories lays out the proposed solution (read: expenditure of money) in a clear, concise, organized fashion, and leverages the Client’s own business goals and logic to justify the project. When a Client can read that this money spent will do x, y, and z right next to “our business goals are x, y, and z”, they are much more likely to make the connection that will turn that light bulb on over their head and produce their checkbook.

But wait…there’s more (besides not being sold in any store)…in addition to Client comprehension, the inclusion of Stories also plays it forward by being the foundation for Scrum and the Achieve Approach within our own Company. This will allow a formatted vehicle for true Client communication all the way through our enterprise in a procedural, Agile fashion. A Story that has been approved by a client-side decision maker allows the Product Owner to get that signature line that says “this is what we are going to deliver for you”. The Lead Developer, ScrumMaster, and Team now have an official from-the-Client document that can be negotiated with the Product Owner, then tasked out effectively, and delivered to the Client to their own specification of “doneness” (the bullet list of requirements above). This will enable everyone — from the Client to the PO to the Team to the Business Owners) to all have a central agreement to refer to. At least to me, this seems a heck of a lot more Agile than arguing the meaning of paragraph 5, page 215, of the Technical Specification document version 1.13 referring to Wireframe #522.

As a Certified ScrumMaster at Achieve — and the Scrum evangelist — I take a lot of crap from my beloved Lead Developers because everything I do or say has to embody Scrum in it’s highest form. Now, no matter what I ask of them, large or small (could you remove my unpublished blog from the published blog list please? could you PDF this web page for the CIO please? Are you ever going to pay me back my two dollars?) the response I always get is…

Story please!

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