Priorities

One of the keys of Agile is Business Value. Everything is about Business Value. If you’re working on something you should be asking yourself, “Will this produce Business Value?” And, to the extent you can know, “Will the Business Value be worth the effort?”

So, if there’s a business need to get a new widget on the main screen that will link you to a new function, for example, you can be asking, “Will users actually use this function? Is it an important enough function that the trigger needs to be on the main screen? Can it be in a menu or in a subordinate screen? How do I turn this into high Business Value?” Then there are the ancillary questions such as, “Is it less valuable if I delay? Would it be more valuable if I built it sub-optimally now and got it out to our users and then optimized it later?” These are all good questions and they help us focus on the most meaningful tasks to the bottom line (which is the company or project making enough money to keep us employed).

But there are some thorny questions that we sometimes forget to ask, generally because we’re optimists and we assume things are going to go well. Here’s a big one. What’s the business value of adding a validation to a field? In a happy path scenario there’s none. But an old QA rule is that anything a user can do some user eventually will do.

I recently built an application that didn’t validate the user entered a first and last name. There was no use case for either name being empty. But, sure enough, someone came up with a reason to enter a record with no first or last name. The last name didn’t actually cause a problem (although it would have made the information useless). The first name created a disaster.

Fortunately for me, it wasn’t a disaster in an important application like user banking. Still, it was embarrassing. Because I was so focused on creating additional features with Business Value, I never put in code to ensure first and last names would be entered. (And I really should know better.)

At a higher level, what’s the Business Value of a good unit testing framework that can report to your continuous integration tool? If you don’t have a problem with regression bugs there’s not much. But does that scenario actually apply to you? What’s the Business Value of putting lots of logs into your application and making sure you have good log management tools? That depends on how badly your system crashes when it’s in production. (I can say I had logged things correctly so I found my blank name bug very quickly, but it’s still embarrassing.)

Make sure you understand the Business Value of these infrastructure issues. If you don’t prioritize them properly their absence could create a high negative Business Value. Rushing features into production without considering these is an invitation to disaster.

Advertisements
This entry was posted in Quality Assurance and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s