About a year ago I wrote an article on Story Narrowing to break down work into small valuable pieces our customers could use. I am revisiting this topic to see if what I have learned in the past year changes my views or approaches in any way. I want to do this by looking at the same stories I made up in that article. But first…
I do not claim to be an expert and definitely am not claiming that the way I do this is ‘the way’ you should follow. Far from it. I also firmly believe, and through some conversations with cohorts, have come to realize that most ideas can easily be attributed to ‘the soup’ or ‘the stew’ of other people in the world experimenting and sharing. As I mentioned in the original article, the term of ‘narrowing’ came from Neil Killick and his Rubik’s cube vs apple comparison.
I am sharing this post for three reasons.
- If it helps anyone than that is great!
- Have people poke holes in the way I approach narrowing stories, and that is also great!
- To hear from others how they are narrowing stories, and that is excellent!
Here we go…
Story Discovery
When narrowing stories, really any kind of work but I like to use stories, it is important to not lose focus of the value we aim to deliver. I think we do this by asking a question like:
‘What is something we can quickly deliver to our customer that will help them?’
I phrase it like this for me as a reminder that the software we deliver is helping to solve a problem for our customer. In essence making their lives easier. And I have yet to come across a customer that doesn’t value someone helping them make their lives easier in some way.
Often times, we work on or with teams that have internal customers and users. This approach still applies even when a proposed solution has been provided to the team. At that point, it is of greater importance to not only ask the question above, but also:
‘Since our customers have problem X, what possible ways could we solve that?’ or;
‘If we deliver the proposed solution, what value is this to the customer?’ followed by;
‘Do we think this is a good way to provide value?’
In any case, these types of questions helps remove us from the mindset that we have the solution figured out already and we only need to figure out how to get it done the fastest. Speed of delivery questions come later, but with this, the mindset is focused on trying to figure out what is a valuable problem to solve and what choices do we have to solve it.
Revisiting Original Post Stories
In the original Story Narrowing article, I provided already written stories as examples. The first thing I would like to do is take those examples and step back to the value question that was asked that led to the stories.
Our first example: “In order to prevent funding loans with missing information, Mortgage Loan Auditors apply suspense conditions to loans and save their changes.”
The original question was: “What is something we can quickly give the Mortgage Loan Auditors that allows them to stop loans?”
The reason this question was great; it lead to fantastic conversations. We talked about why a mortgage loan auditor would need to stop a loan? And what do the mortgage loan auditors do today to stop a loan? What happens to the loan once the mortgage loan auditor stops it? What are the consequences if a loan isn’t stopped that should have been? Things of that nature and more. The original story I shared was not the only story that came from these conversations, but it is the one I chose to share as an example of splitting vs narrowing.
So what would I change a year later from this story? Not much I don’t think. But I like to think about things while I write them. So let’s go on this journey together.
At some point we found out that the mortgage loan auditors needed the ability to prevent a loan from being funded, and that took center stage on this story for the why. Yes, I like to focus on, and even write, the why first often times.
I think we could have narrowed that story a little more if we wanted too. In the first part of the story “In order to prevent funding loans with missing information…” we identified a condition of acceptance criteria without realizing it. “with missing information…” gives a condition for why, in this story, the mortgage loan auditor would be stopping the loan. There are a number of reasons why, but this story was focused on missing information. What missing information? Well, any missing information. And there was a spot to narrow.
I guess today I may try and say: “In order to prevent funding loans, Mortgage Loan Auditors apply suspense conditions to loans and save their changes.”
But that then leads to another possible narrowing point. “In order to prevent funding loans…” Are mortgage loan auditors stopping multiple loans all the time, or one at a time? Do they need the option to do both?
So maybe it would be better to say: “In order to prevent funding a loan,…”
Ok, we have narrowed out from a condition of missing information and from multiple loans to a single loan. That feels better to me at the moment. I guess we could get wording different and say: “To prevent a loan from being funded,…” but really what is the difference? I had the thought for a second, so I shared it. Moving on…
So our narrowed story looks like this: “In order to prevent funding a loan, Mortgage Loan Auditors apply suspense conditions to loans and save their changes.”
Something I am thinking about right now is does this apply to any and all loans, or is it a specific type of loan? Well, that would be a detail that may not be necessary to define right now. But it is a question. If we were constrained by a specific type of loan, I guess we could call that out in the story. Feels the same as “missing information” was. So I will leave it out.
In the next part of the story we have “Mortgage Loan Auditors apply suspense conditions to loans and save their changes.”
Ok, we have our who with the “Mortgage Loan Auditors”, so that is nice to have. And we have what they do with “apply suspense conditions to loans and save their changes.” Right from the start, I am eliminating the “and save their changes.” What good is it if they can’t save their changes or if the changes don’t automatically save and update.
So now we have: “In order to prevent funding a loan, Mortgage Loan Auditors apply suspense conditions to loans.”
Well would you look at that, multiple loans again, better fix that too.
Here we go: “In order to prevent funding a loan, Mortgage Loan Auditors apply suspense conditions to a loan.”
What the hell is a suspense condition? As part of those conversations that took place with the mortgage loan auditors, we were able to define some terms, or as I have learned in the last year to refer to them as our “ubiquitous language” that fits within our “bounded context”. Domain Driven Design is a great thing to dig into if you have the time. Suspense conditions are what mortgage loan auditors call the things they put on loans to prevent them from being funded. There are a bunch of them. With that knowledge we could have narrowed to applying a single suspense condition to a loan. Or we could have changed the story to applying a single suspense condition to a single type of loan.
Or we could just say: “In order to prevent funding a loan, Mortgage Loan Auditors can apply a suspense condition to a loan.”
This I think gets at the core of what the mortgage loan auditor needs to be able to do. And it is narrowed down. The details would follow as we began working with the mortgage loan auditor and building out this functionality. We could identify the type of loan to use and a suspense condition to add to it. We would then see the loan is blocked from moving to the funding phase.
I guess if we really wanted to, we could have said: “In order to prevent funding a first time home buyers loan with missing information, Mortgage Loan Auditors can apply the missing information suspense condition to the loan.”
I guess that is fine too. Actually kinda feels like I went on a little journey of a circle and like this version better. Let me know what you think.
But either way, we could iterate on that story for a while. Adding more loan types and suspense conditions and delivering them as we go. Each time providing a little piece of value to our user. In my mind I like this because I can see how I might design this in the code. I do recall having a conversation about this where some of us wanted to just populate the available suspense conditions drop down with all possible suspense conditions. There was quite the discussion about the effort to do that vs the effort to test it. Not all suspense conditions had the same outcome or went to the same queue to be fixed. And that there is yet another seam to narrow. Then again, I could be completely off base. Again, please let me know…
Estimates Section?
Well, apparently I went on a short tangent about estimates in the original story narrowing post. I do not remember why at this point I added that thought there. Perhaps it was just a passing thought and I wanted to add it in.
So a year later what have I learned? Nothing has really changed on this one. Estimates are dangerous not only because of how they are made, but what they are used for. Using an estimate, no matter how scientific you think your approach is, to make decisions on what to build, which projects to do, how to budget or really any other decision in the software development domain is dangerous. And still today I know there are better ways of working that remove the need for estimates. Through continuous delivery and engaging with actual users of the software, we are able to provide continuous steering. And when you can continuously steer, asking for an estimate is really quite foolish.
Perhaps the greatest learning on this topic is Estimates vs #NoEstimates is still highly debated. The most concerning is the misunderstanding of #NoEstimates as a battle cry “we won’t do estimates anymore”. When in reality #NoEstimates is more about finding better ways of working and perhaps pointing out that the practice of estimates is potentially causing damage to the people, teams and organizations that try to use estimates.
This could be true of any rote practice. If we are doing something that we all agree on isn’t helping us or isn’t providing the outcomes we expect, then why should we continue to do it without seeking a better way?
If the problem estimates are trying to solve for isn’t being solved by estimates, perhaps there is a better solution we need to investigate. From what I can tell, targeting getting better at estimates as a solution for predictability in software delivery has proven to be silly at best.
What if we asked the question: “If estimates are supposed to be solving for predictable software delivery for our customers and they aren’t working, what other options do we have to solve for predictable software delivery for our customers?”
Well would you look at that, I used a story narrowing type of question to look at the problem domain of software predictability via estimates. Maybe that is the point I was trying to make in the first post with this section and completely missed the mark.
Closing
I don’t know if these ideas will help you or anyone else. They are just things I have tried or seen others try. Or they are thoughts and ideas I have heard or shared. They have worked and not worked. Much like everything else, we want to try stuff and see what works.
Chris Pipito 