Story Narrowing

I recently spent some time with Allen Holub, and a term we used when discussing Stories and right-sizing Stories was “narrowing” as opposed to “splitting”.

I like the term “narrowing” and spoke briefly about it during an appearance on the Coaches Corner Podcast with Dan Nuemann from AgileThought.

https://agilecoachescorner.libsyn.com/scrum-cling-ons-and-culture-shift-with-chris-pipito

Story Narrowing

Narrowing and Splitting are just terms. But I like Narrowing since it gives a different view or thought process from the people you are working with when using Stories.

Narrowing to me says we are making the Story smaller without losing the value of the whole.

Splitting to me says we are taking all of the little pieces of the Story and splitting them out into different tasks but they are not valuable by themselves. At least that is the mindset I have experienced whenever I talk about splitting Stories.

I am going to use an example from the mortgage industry:

“In order to prevent funding loans with missing information, Mortgage Loan Auditors apply suspense conditions to loans and save their changes.”

Then I would see this Story split like this:

• As an Auditor, I need a blue add button, So that when I click it the button flashes and the suspense condition adding line appears
• As an Auditor, I need a suspense drop down with all available suspense conditions to choose from in alphabetical order, So I can choose a suspense condition from the drop down.
• As an Auditor, I need a green save button for after I choose a suspense condition, So I can save the suspense condition I added.
• As an Auditor, I need a successful save notification when the suspense condition has been added, So that I don’t add it again

Ok so they may not be the worst Stories ever created. But I don’t think they are Stories as much as they are different pieces of functionality of a Story.

To me, their is no value in only having the line to add a suspense condition appear if you can’t do anything with it.

This holds true for having the drop down full of options to choose from. So what, I have the drop down of options. But I can’t add it yet, that is in the next Story with saving.

I would rather narrow the main story to adding a single suspense condition, not any of the possible suspense conditions. Something like:

“In order to prevent funding a loan with a missing internal funding approval, Mortgage Loan Auditors apply the Internal Funding Approval suspense condition and save their changes.”

Maybe with a GWT for a single acceptance test.

• Given the Internal Funding Approval is added to a loan
• When the Internal Funding Approval suspense condition is saved
• Then the Internal Funding Approval suspense condition is added

Then we are getting the full value of adding a single suspense condition to a loan. We can deliver this to a Mortgage Loan Auditor, and get their feedback before progressing further with other things.

I realize that this Story is pretty odd and industry specific. But I wanted to try and use something real from a not so familiar industry.

Neil Killick used an example of I am quite fond of, and not that I expect Neil to ever see this post, but I need to apologize for stealing this example on the podcast mentioned above as I could not recall where I had heard it from. Sorry Neil.

The example Neil used is that of a Rubik’s Cube and an Apple when it comes to slicing a Story. And it goes something like this.

If you break up (Split) a Story like a Rubik’s cube by taking all of the squares off of the cube and building them one at a time, they are not deliverable on their own to understand what is being provided.

On the other hand, if you slice (Narrow) an apple, and throw away the rest of the apple, the slice is still valuable to the hungry person. They can eat the slice of apple and know that it is apple.

Using this description, and looking at the Story above with suspense conditions, I argue that the “add button” is a piece of the Rubik’s cube. And by itself, delivers no value to the Mortgage Loan Auditor.

Providing the ability to add a single, specific suspense condition, is a slice or a narrow path through the functionality of the Mortgage Loan Auditor adding suspense conditions to loans. This is a narrow path since there are multiple suspense conditions that are available, and could be added at the same time.

Now I think, and I might be wrong, but the above story example may be more of a Functional or Technical Implementation narrowing. This way of narrowing stories is still extremely effective and often times needed depending on your domain.

Let me try what I would think is what falls under a Story narrowing by user Capability.

“Enable our customers to apply for a mortgage loan on-line and track the progress of their mortgage loan applications to completion.”

Then we could narrow this Story in a multitude of different mortgage types:

• Residential
• Commercial

Or we could narrow this Story by customer types:

• First time home buyer
• Investor
• Repeat customers

Or we could narrow this Story by how the customer might apply for the mortgage through specific channels:

• Web Site
• Mobile App
• iPhone
• Android

Now if we narrowed by say First Time Home Buyers using a mobile device, we might say something like;

“Enable first time home buyers to apply for a mortgage on our website using an Android phone.”

That is a “User Story”. It is something a user can and will do. It gives us something of value to target that we can deliver in a month or less. This provides us with valuable insight into our next decision. What do we do next or if we should kill that product.

You will notice that I left off the part about tracking the mortgage loan through its process. My brain says that is another Story.

“Enable First Time Home Buyers to track the status of their mortgage as it moves through the mortgage application process.”

Now the argument I might get here is, “this is a very big story”. Yes, it is, there are a number of things that go into this. But Stories are not just something the development team does. This “Capability” Story may end up being sliced into a number of “Functional” or “Implementation” Stories.

#ProEstimates vs #NoEstimates

There is, to my knowledge, no “#ProEstimates” movement out there to battle with the “#NoEstimates” movement, but that is how I am choosing to describe the two views.

I have had the conversations with the #ProEstimates folks who want to say that if you are “right-sizing” Stories, then you are estimating, so we can stop with the #NoEstimates.

Well, I will concede on that point. If the #ProEstimates folks would use right-sized Stories as a means of estimation instead of some arbitrary numbering scheme being forced on teams. And calculating all of these numbers together in an effort to have yet another arbitrary set of milestones and deadlines meanwhile changing all of the “requirements” as we move along and holding the teams feet to the fire on the original arbitrary set of numbers, milestones and deadlines. And by the way team, why aren’t you done yet?

Closing

I have been working with Stories for roughly 10 years, and I know I have a lot to learn about using Stories. But learning different approaches and what others have done that help them is something I love to do and try for myself. I will try a number of different techniques and approaches. Some will work great, and some will be completely terrible. Use what I share to your liking, or tell me I’m a moron and correct me if you feel I am wrong. I am always open to hearing feedback.