Is Scrum a Framework or a Methodology?

I am so sick of this conversation. I CAN’T TAKE IT ANYMORE.

I write a lot about Scrum and, God forbid I should accidently call it a method or methodology. Invariably, some bonehead will comment “It’s not a methodology, it’s a framework” and then go off on a tirade designed to show just how smart they are. And then all the other boneheads go off-topic chasing bonehead #1.

I know because I used to be that bonehead. (I apologize)

I get it. It’s a framework. It’s a framework. Yes, dear God in heaven, it’s a framework. But most of the times when I’m writing about Scrum, I’m discussing a specific step or rule that is part of the method that partially defines the framework. Other times I want to mention all the methodologies that are associated with Agile but again, I have to differentiate Scrum as being a framework.

So, I have created a new word and hashtag; #FrameMethod and a hyperlink to this post at http://bit.ly/2oBGBtX to explain what it means and how it can be used. Which can also be added as a link FrameMethod

I intend to use it instead of the words method, methodology or framework whenever I am writing about Scrum, as in:

“Scrum is a framemethod…”
“Scrum is a #framemethod…”
“Extreme Programming, Kanban and Scrum are just some of the #FrameMethods that are often connected to the Agile philosophy”

This completely eliminates the bonehead factor. (I did apologize for my past boneheadedness, right?)

As mentioned above, it could also be used to describe the methods that are part of the Scrum framework, as in:

“Scrum is a software development framework that comprises a number of principles and #framemethods”

#tapft

CRAFTING USER STORIES

Suzy: Daddy, tell me a story.

Dad: Certainly sweetheart.

As a: Business person
I want: You to go to sleep
So that: I can go back to reading sales reports.

Suzy (Angrily): MOM, HE’S DOING IT AGAIN!

Have you ever noticed that articles about creating user stories never talk about the fact that it is called a story because it is supposed to tell a story? People know how to tell stories so why not let them?

Personally, I have found the “As a:, I want:, So that:” format to be restrictive. I have also found that it tends to stifles real communication (an Agile no-no).

If you think about it, software development is all about storytelling, with three basic types of stories:

What & When
How & When
Why

The customer or end-user tells us What they want and by When they need to have it.

We, the technical folks; usually business analysts, architects and product owners, work with the requester to clarify the story of What and When.

We then start writing, first at a very general level, the story of How the request might be fulfilled and When this might happen.

The story of Why is a very important story that often gets overlooked. It should be more than just “so that I can do X, Y, Z”. In fact, the story of Why is the thing that allows us to be agile. It identifies what is really important to the user and thereby tells us where we can be adaptive if we need to be.

For instance; if the Why is to reduce cost, then perhaps the user interface design is less important. If the Why is to increase sales, then fully developed functionality may not be as important (a.k.a., Lean Development).

The story processing itself is that we continue to refine, clarify and breakdown the stories of What and How and When to the point where we have everything we need in order to go into production.
Think of it like writing a book, a novel. We start with the basic concept. We then do an outline followed by fleshing out the parts and sequence of the story.

Jumping now to the bottom of this particular metaphor; think of sentences as the thing the programmers create. At the beginning of the Sprint, no one knows what those sentences are going to be. Everyone does know what story the chapter needs to tell (the Sprint goal).

In the Sprint, the programmer writes the sentences which make up the paragraphs. Each paragraph tells its own little story which can be confirmed by the testers. The paragraphs are then combined in the proper sequence to create the chapter which is itself a self-contained story (a potentially shippable iteration).

Lastly, we put together the chapters to create the book that tells the story of our product and over time, the collection of books comes together to tell the story of Our Product Library.