Does what I do have any business value?

One of the main strengths of agile methods is their focus on value-driven development. Whether we are planning releases, prioritizing features, or writing tests, we need to always ask the question: does what I'm doing provide any business value? Because if it doesn't, we simply should not be wasting our time doing it. For example, after long battles with traditional practices like elaborate documentation of requirements and design, we have come to know that writing lengthy documents in itself does not provide business value.

But what is business value? 
Different academics and practitioners have their own perceptions as to what constitutes business value. The most common understanding I have seen though is that business value has to mean something to your end-user. Somewhere in the definition you need to find the word 'customer' or 'user'. For instance, a work item X is said to have business value if it provides usable and useful functionality to the 'end user.' A test T has business value if it provides a guarantee that the system will not crash when the 'end user' attempts to do a given task. A document has business value if it enables the 'customer' to prove their conformance to ISO 9000 for example.

Keeping business value in our radar is as important as any other principle in agile development. A good understanding of what creates business value to the customer reflects good requirement elicitation practices, effective communication with the customer, and a higher probability of delivering something that is useful and usable.

Estimating/measuring business value
Ask anyone who went through the exercise of estimating the business value of something, and they would tell you it is not an easy ride. Putting a value tag on a story card or a feature is very tricky. For one, we need to have an excellent understanding of the big-picture in order to measure value in relative terms. What seems very valuable to someone who just joined your team may seem to you absolutely valueless given the other things you have in the backlog. The second reason why estimates may be difficult is due to the concept of 'total value'. Mike Cohn did an excellent job explaining this concept. But in summary, the value of certain parts (e.g. stories) of a larger entity (e.g. system) may be too difficult to measure because without these relatively small parts, the entity as a whole is useless. Think about the value of the screen of your laptop!
I strongly recommend that you read Mike's blog post on this topic.

Does business value have to be customer-centered? 
I believe it should not. I will explain this further.. not today though.

So..
If you want to take one thing from this short summary of business value, then here you go: question everything you do in your software development to determine whether it is worth the effort or not. Be it a feature, a process, or any other thing that consumes your time, always ask: Does what I do have any business value? I have a colleague who conducted research in a major IT company to study the flow of information through the organization. He traced a lengthy report that was regularly produced by one department in the company and had to go through a number of review processes. Eventually the report would land in Juan's drop box. Juan had left the company 2 years ago.