Tech Stories are Business Stories Too!

"Say What?"

One thing that I seem to be hearing a lot of lately is that "Tech Stories" aren't "Business Stories" and thus shouldn't be subject to prioritization by the Product Owner.  I beg to differ.

Tech stories are just as much business stories as any other story that we play.  That they provide some value to the system being developed means that they are also providing business value; the system is being developed to serve the business.  If the system doesn't have business value, we have no business developing it.  Similarly, if a story doesn't have business value, we don't have any business working on it.  So, because the technical stories are providing business value, they should be subject to the same prioritization as any other business story.

"But, my Product Owner just doesn't understand why my Tech Stories are important!"

It's your job to help your product owner understand the importance of the story in terms that they can understand.

Yes, you heard that right.  You are the one with the technical expertise and knowledge, so you should be able to explain to your Product Owner why your technical story is important.  If you cannot explain to your Product Owner why it is important in terms that they can understand (i.e. in terms that relate to business value), then perhaps your technical story really isn't that important after all.

If a technical story is designed to provide better error handling around one section of the system, then it's up to you to explain how better error handling around that section of the system will provide business value to your Product Owner.  For example, the better error handling may mean less frustration on the part of your users.  Or, it may mean that Level 2 Support may be able to more easily diagnose and address the issue, which would result in fewer problems being escalated to Level 3 Support (which is likely much more costly than Level 2 Support).

"If I just tell my Product Owner that the world will end if we don't get to play this technical story, I can get him to let me work on it right away.  Why bother with trying to figure out the real business value behind it?"

Because, if you aren't providing him with an accurate impression of what the true business value is of your technical story, then you aren't doing your job to provide the best business value that you can, as quickly as you can.  Your technical story may be providing much less business value than several of the other stories that have already been given a high priority.  It is your job to give your opinions and advice to your Product Owner to help him understand what the business value of some stories are (or to occasionally nudge them away from "want's" and back toward "need's").  But, it isn't your job to determine what is going to be the highest business value for the business -- that is your Product Owner's job.

No matter what the technical story, there is business value within the story.  It's up to you as the developer to help your Product Owner understand the business value in it so that it can be prioritized correctly.