Posts Tagged ‘Story’

Here’s the backstory: currently on Facebook, it is all the rage to use your Notes application (read: blog) to write up 25 random facts about yourself, then “tag” 25 other people to make them have to do the same thing. Personally, I think that this was started by the Facebook people themselves as a way to introduce people / drive traffic to the Facebook blog functionality, and since my WP imports via RSS to FB, I figure I’d do it here so that people can get their fix and stop tagging me.

Original rules (as in, I didn’t write this schlock):

“Once you’ve been tagged, you are supposed to write a note with 25 random things, facts, habits, or goals about you. At the end, choose 25 people to be tagged. You have to tag the person who tagged you. If I tagged you, it’s because I want to know more about you.

(To do this, go to “notes” under tabs on your profile page, paste these instructions in the body of the note, type your 25 random things, tag 25 people (in the right hand corner of the app) then click publish.)”

25 Random Things:

  1. I am a better human beat box than Justin Timberlake
  2. If you ask me what one word describes me best, I will always reply with “lucky”
  3. I still suffer from ADHD just like I did when I was a child, but I am better at masking it; I do wish, however, that my metabolism had kept up with the rest of the handicap
  4. I have always been in love with being in love, with music, with friendship, with my family, and with you
  5. I have been known to embellish a story or two, but usually it is due to my tendency to describe my friends and acquaintances as movie-worthy comic book heroes, which is born from a deep respect for their individuality
  6. I often wonder what would have happened if Monster Zero had accepted the gig to open up for No Doubt on their first West Coast Tour in the summer / fall of 1990
  7. I would be happy if I could just listen to music, select cool tracks, and play them at loud volume to interesting people all of the time
  8. For some reason, in some election I was not made aware of, I am the de facto communications hub for a bazillion people; you look up Murdoch if you want to randomly communicate with someone who you lost track of years ago, and somehow I have some sort of last known contact info
  9. Possibly the greatest thing I have ever done is the eulogy I gave Chris Feher after he died doing what he loved: rock climbing Half Dome in Yosemite by himself
  10. I hate children, especially babies, but apparently, they love Unkle Mike, and this fact never fails to humble me
  11. Speaking of luck, I was lucky enough to be adopted at birth by the best parents in the world — Diane and Gordon — and what I can piece together about my biological parents is pretty crazy: Mom was from Massachusetts, married, and had three other children, aged 8, 9. and 11 when I was born; her husband was NOT my father; she was short, Swedish, and had blond curly hair; my dad was an Italian steelworker, son of an immigrant shoemaker who woke up one day to find a note from his wife that she was leaving him and half of the closet was gone; Mom’s husband had a nervous breakdown and was committed; this explains a lot of what is running around in my genetic pool — don’t blame the Murdochs
  12. I am the best party liaison this side of Van Wilder
  13. I have three home-produced album to my name under various alter-egos (see Pus & Zero Boy) and one professionally released 12″ single called “Everybody” that I did with Grant Goad and Andres Mijangos
  14. I am still very proud of all the work I did to become an Eagle Scout
  15. I wrote poetry every day for almost 15 years; most of it is available — tagged and searchable even — on my WordPress blog; my current favorites are “Cellardweller“, “I, Ape“, and, of course, “Froggacuda
  16. I often wish that everyone else could hear the soundtrack and audio effects track that accompanies my life
  17. I am a pack rat, especially for things that provoke nostalgia; for example, I still have many of my childhood toys — Legos, Transformers, Micronauts, etc. — and a box full of the stuff I had pinned / nailed to the walls of my room when I was in high school, such as Fishbone ticket stubs, a referral from Coach T (R.I.P.), and extra pictures of hot chicks I had crushes on from Yearbook class
  18. I have always owned a “strange” pet as well as my beloved cats ever since Linda Nickel bought me my first Emperor scorpion; currently I have Tuonetar Mac Mordenkainen, who is the third Mexican Red-Knee tarantula in a long line of wonderful arachnids I have loved
  19. I don’t code Web 2.0 anywhere near as well as I did Web 1.0
  20. I love jackets; first and foremost is my ska-patched black jacket, which used to be a bomber, but out of all the clothing you can wear, nothing beats the right jacket for the right occasion or situation
  21. I have been a true (4 elements, y’all!) fan of hip hop ever since seeing the Sugar Hill Gang perform “Rapper’s Delight” live on Solid Gold 1979; this seminal moment changed my life forever
  22. There is nothing better in life than having a good conversation filled with enthusiasm, a meeting of the minds, and laughter
  23. Being rejected in junior high school by the popular white folks as a glasses-wearing, uncool, too-smart nerd has served me well; I have good friends and strong cultural ties to non-white communities who have accepted me for who I am from then until the present day; this is one of my greatest sources of pride and what makes me wince when I have to choose “caucasian” on “optional” survey information
  24. I love language, especially since the world is made of it (see the collected works of Terence McKenna), and I have a fierce propensity towards sesquipedalianism just because long, multisyllabic words sound cool and are sometimes the key to doing what Salt & Pepa, Madonna, and Dr Dre during his NWA tenure said best: expressing one’s self
  25. There is nothing I value more in life than my friends; they are the Desiderata of my happiness, the real value in social networking, and many times, the only reason that I keep on keeping on, because I can’t do it all for myself

There we are: 25 random things about me. Feedback — as always — is very welcome. Have at!

“…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!

At the 2007 Achieve Summit, Gary Markowitz presented The Achieve Approach. This is — from my point of view as a ScrumMaster — essentially a scalable series of questions that needs to be asked and acted upon for each and every thing that an Achieve Team does, no matter how large or small the chore is. To quote Chuck D from Public Enemy, “here come the drums.”

The Achieve Approach consists of four items:

  1. Discover
  2. Architect
  3. Develop
  4. Deploy (or Launch)

If you look at these items as a series of questions that are to be asked of every Task, Story, Project, Sprint, or other work that we do at Achieve, we have a framework to insure that the Team is thinking through a problem, rather than rushing to Development and missing critical bits of information that later crop up as impediments. Even though it may seem — at first blush — a little ridiculous to ask these questions for every Task that a Team creates for a Product Owner’s Story, the scalability of the Achieve Approach will make this a valuable exercise.

Scalability means that a routine (in this case, examining the four parts of the Achieve Approach) is suited for both large and small applications, and that it is nimble enough to apply equally in micro- and macro-environments. The Approach seems to be built for a Project: these four steps are “phases” or “stages” that are dealt with in order to be able to produce the needed information to move to the next stage or phase. This type of approach will be derided by hard-core Scrum practitioners as “waterfall methodology.” Just the fact that you have to complete Discovery before you move on to Architecture sends CSMs into a foaming-at-the-mouth frenzy. “This is not Agile! Waterfall is for lumbering oafs! We don’t need no stinking Discovery!” Although there is some concrete value in having a phased approach, Scrum itself loathes this sort of Six Sigma PM thinking because of the perceived waste of time that comes from doing classical due diligence with rigid phases.

That is not what the Achieve Approach is about. The scalability of the Approach is what keeps it Agile. At a Project level, there may be specific phases that Achieve walks through in order to insure that when we hit the Development phase, we have all of the information needed to successfully Develop. At the Scrum level, it is much more of an Agile process where we simply ask the four questions on a per-Story or per-Task basis in order to bubble up impediments before they interrupt the Sprint. Ingraining these four steps into our everyday thinking should help us ask the questions that need to be asked in order to provide accurate estimates, the correct number of tasks, and bite-sized chunks of work to insure that we can deliver quality and timely releases to our Product Owners within the timebox of the Sprint.

Here’s a real-world example of the Achieve Approach working in a Sprint in question format:

STORY: As a [client developer] I want to be able to [easily theme the four verticals on my website] in order to [implement the new Rotato without making it look like it is a new part of the website]

REQUIREMENTS: [simple functional specifications and use test cases as provided by the Product Owner] — this is to be addressed in a later Art of Scrum

TASK IT OUT: Normally, the Team would start throwing out sticky notes with tasks on them in order to try to meet all of the requirements that were laid out by the Product Owner within the Story; here is where, as a ScrumMaster, I am going to ask for the Achieve Approach to be considered.

  • Scrum it up and bounce out all of the Tasks needed to complete the Story
  • Arrange the Tasks in the order that is needed to complete the Story
  • Keep in mind the Team’s resources, and if Tasks can be done in parallel — this is important for Agility
  • Have the Team consider the four elements of the Achieve Approach: even if it takes 15 minutes extra per phase (mostly Discovery and Architecture I am guessing) it is massively important to think these things through at the Planning Scrum so that estimates are accurate and that the Team does not incur Technological Debt
  • Perhaps each Task can be labeled with the Achieve Approach steps in order to insure none are missed

START SPRINTING: If an impediment occurs, again run through the four elements and see where the impediment was missed, if applicable

DELIVER THE GOODS: Make your Product Owner feel like a Hero by giving them a Product that they cannot wait to demo to their Stakeholders

I would like to see Achieve be able to understand Projects, Stories, and Tasks — especially with their resulting impediments — categorized into Discovery, Architecture, Development, and Deployment so that we could understand better where additional work is being generated by not thoroughly planning ahead of time. Although Scrum is designed to deal quickly with problems as they arise, I still feel that the best way to avoid problems is to think them through in the first place. Perhaps we as a company are not doing enough Discovery. It may be that we are arrogantly trying to Architect on the fly. It could be a common misconception that Launching (or Deploying) is a simple push-button process.

This is a rather long blog (hooray for Nyquil), but the upshot is this: learn it, love it, repeat it: Discover, Architect, Develop, Deploy. This mantra will become a saving grace as we find it reminding us of the path to quality code and products.

Once upon a time, there was a project that was supposed to be done at the end of the month. There was a full Product Backlog, some of which was well defined into twelve Stories, and an enthusiastic Team ready to tackle the four week-long Sprints it was expected to take to finish the project. Confidence was high, and the predicted due date seemed to be no problem. Flip the hourglass with the sands of time; enter: Reality.

Once upon another time, a college student was given a credit card. Charge all you want and pay it off at the end of the month and it was like getting an instant, interest-free loan. Payday is the 30th (read: end of the month), so let’s get some shoes.Again, enter Reality.

Both of these scenarios, when adding the cosmic constant called Reality, are the beginning of accruing debt. In Scrum terms, technological debt is that work that is NOT done when trying to hit a predicted due date once reality enters the picture and starts to pump chaos into the well-sculpted predictions made at the beginning of the project. Another way to look at technological debt is to think of it as credit card interest. If the Team can hit the predicted deadline dead on (pun intended), no debt accrues. But any deviation beyond the due date creates a situation where, when normal business pressures come to bear, compound interest starts to make things interesting.

Let’s expand my first example. Sprint week one: an Impediment arises that chews up four hours of productive time during the Sprint, causing the third of three Stories to not be completed properly. Planning Scrum for week two: this issue bubbles up to the surface and is taken into account by using the second week Sprint to finish the work not completed on the first week’s third story. This causes the Team to lose Velocity and only complete two stories in the second week. The Team now completes the second Sprint, and has a total of five Stories complete in a quality manner — code is solid, all testing is done, and the work is up to par. Now, halfway through the project, this is noted, but optimism is still high, and somewhere in the next two Sprints, this extra Story needs to get done on top of the remaining six . This is not yet technological debt, but it should be cause for concern for the Product Owner, the ScrumMaster, and the Team. Interest is looming.

As the two final Sprints are planned and executed, somebody comes up with a fabulous idea of a shortcut to keep the project on track to be delivered on the predicted date. These ideas are usually along the lines of not completing due diligence on testing, outputting hacked code, skipping code reviews or full QA, or otherwise not doing high quality work. Project is delivered, client and Product Owner look like heroes, and everyone is happy, right? Wrong.

Technological debt — or interest — exists in the product itself. The entire Team — Product Owner, ScrumMaster, and Team Members, all know that within the delivery lurks something that was not up to par, and may come back to haunt them later. Extrapolating my second example — including the introduction of reality — at the end of the month, it is more important to pay all of your rent and only part of the credit card bill, so your $300 pair of shoes only gets $250 dumped on the bill. Waiting until the end of the next month to pay for your new clogs will actually cost you $75 more, not the $50 that it would have taken had you paid the whole thing promptly before the interest rate started getting that rear-naked choke hooked in. Technological debt works the same way. Your shoes just cost you $325. Next month, as the compounding really gets rolling, they will be a $350 pair of shoes, all the while losing value while you are wearing them to your Scrums every day.

Back to example one: client is so happy with the delivered product, they want it installed on all three of their websites, and expects that it should be an easy chore. We delivered them a quality, scalable, perfectly-factored product, right? Unless the technological debt is addressed immediately in the new estimates — probably a whole week’s worth of Sprint on top of this new client request — the problem is not just going to sit there and be a static problem value; it is going to gain interest. As the product is scaled, built upon, sold as-is to other clients, this debt is accruing interest. As long as this debt is ignored, it will continue to compound and cause problems in the future, especially in terms of codebase. Technological debt really gets good when the programmer who put the hack into code in the first place either is no longer with the Team or doesn’t remember what was done to create the problem in the first place. Time is the factor that is compounding — in this case, to find the problem and fix it. The sharpest pain in the process of catching up on technological debt is that there is nothing that can be sold to the client as an upgrade or a new feature; this was supposed to be done in the name of Quality last month…or six months ago,,,or whoever the dude was that built this code in the first place.

One of the central concepts of Scrum is honesty. Honesty within the Team is crucial, and in the case of this example of technological debt should have been clear communication to the Product Owner that due to the Impediment, the project needed another week to be delivered with the quality that the client deserved. If the client could not wait one more week for a quality product, then the Team has to get a Business Owner involved — usually to OK overtime, working lunches, and otherwise reducing other responsibilities in order to retrieve the additional time to do it once and do it right. In the case of the shoes, you would have saved your money and purchased them the 15th of the next month when you could drop $300 in cash and not absorbed any debt in the first place.

For a good graph-and-chart-laced article on the issue of tech debt, check out Technical Debt and Design Death by Kane Mar.

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!

Green Monte Carlo

Posted: October 16, 1997 in Writing
Tags: , ,

I used to own a 1973 olive green Monte Carlo. It served my family quite well until I really learned how to drive; it was Shelby Brown who convinced me to see how high I could launch it above the ground one lifeless night in San Diego. Shelby Brown has a penchant for getting me into trouble: my parents frowned on him for “borrowing” this same car without my permission from a party and returning it an hour later with a half-tank less gas and the excuse that he was jump-starting his car down the street. This night, though, I remember him looking over at me with a slightly surprised expression as the engine was roaring at 5500 rpms since the wheels were no longer in contact with the ground. As I lifted my foot from the gas pedal, and the engine noise died to a faraway murmur, Shelby had time to say “Gee Mike, we’re really high.”
The rooftops of cars were passing below the tires of that green Monte Carlo as we flew down Dickens Street.
My friends Chris McGee, Brett Hathaway, and Matt Graham were in the back seat staring at the San Diego Bay’s skyline through the windshield. Dickens Street is in a moderately well-to-do part of Point Loma, and the views from those houses were magnificent. The intersection that had enabled us to defy gravity for a few precious seconds was at the top of a hill that had a sudden gradient change from steep to steeper in the middle, and ended one short block down in a T intersection which crossed Dickens, not continued it. What made me acquiesce to Shelby’s request to power my poor seventeen year old Monte Carlo down this street at 43 miles per hour is, to this day, beyond me.
The five of us had thought to go to one of a few parties we knew of, but nothing was happening. The Monte Carlo was a very unique car; only Chevrolet in the early part of the 70’s would have been able to sell my father on that color, and it was one of the favorite rides to and from parties. Plus, the large bumpers and the couple of dents put in it by my parents on ill-placed light poles and tight parking spaces were adequate to cover up any small damage we would do to the bodywork while driving down alleys spinning trash cans with our momentum. Most of the purpose of taking the Monte Carlo was the diversions that we would find on the way to and from parties. Dickens Street bent the steel frame of my car, almost sent the five of us over a cliff into the roof of a Vons forty or fifty feet below, and was the most talked about event of the next three weeks among my friends. Nobody ever convinced me to do it again, though.
The top of the street had a huge dip and bump in it; it was this which propelled the car into the air in the first place. The unique design of the street, getting steeper halfway down, gave us even more hang time once we got there. The 1973 Monte Carlo was a heavy car, even for those days of the V-8 engine and the swivel bucket seats; when we came down, we landed partially on the front bumper. The impact of the automobile jarred the engine in its motor mounts, and it stalled. Heading towards a sturdy white fence with three reflective red diamonds on it that guards a large cliff is no time to lose your power brakes or your power steering. I hauled with all my might on that steering wheel, driving around a parked car on the wrong side of the street to its left, over a curb, some shrubs and a lawn, through three galvanized trash cans and back on to the street. As the car rolled down yet another hill, but at a lesser speed, I shakily put the car in neutral and started the engine. We drove on in silence, down and around to the parking lot of that Vons.
When we got to the supermarket, I stopped the car where we could all see the white fence. I opened my door and climbed out. I let the occupants of the back seat get out and walk around. Everyone had the look you have after getting off of the Viper rollercoaster at Magic Mountain or after seeing a movie like “Die Hard”. Shelby, though, was having trouble getting out of the passenger’s side. I walked around the car, checked to see that the door wasn’t locked and hauled on the handle really hard. It finally swung open with an awful squeal, and Shelby got out. Matt pointed to the roof of the car, where there was an almost unnoticeable crease in the paint: the car had compressed a little in the thin material of the roof. That meant that the frame had bent on my Monte Carlo – it was why the door on Shelby’s side didn’t fit quite as precisely as it was designed to fit anymore.
I drove everyone home after that; nothing could top that incident off, so we just talked about it as everyone was delivered in the remarkably durable green Monte Carlo. The next day I told my Dad that I had hit a dip a little too hard on Ebers Street, famous in Point Loma for its gaping, canyon sized dips. A few months later, the mechanic who was changing my tires for me pulled me aside and asked me what I did to my car. It was up on the lift, and he pointed out that the A-frame which holds the right side tire on the axle was bent and twisted just a bit. I swore him to secrecy and explained the “Dickens Street Leap” as we had dubbed it, and he looked at me as if I was crazy.
Maybe I was crazy back in high school, but Dad and I sold that Monte Carlo this time last year, and it was only after we had sold it that I admitted to him what I really did to it to make the door squeak so horribly. And I never admitted to him that Shelby Brown was in the passenger seat.

Once Upon a Time…A Story

Posted: September 29, 1996 in Poetry
Tags: , , , ,

Once upon a time I wrote a story
Which caressed the face of the girl I love,
But the real life situation
Is untenable.
She has lost sight of what I once was
In my prime, in my heyday,
And this stubborn pride
Speeds my fall.
Once again, the impact will wake me
To a life in shambles;
Nothing gold can stay.