Story Cost & Story Value

I read a complaint recently along the lines of "why do we still fill in timesheets?" There was a lot of opinion from the conservative "that's how project accounting works" to the radical "we don't need them". Somewhere in the middle, timesheets are relevant, useful, & painless.
These three things are not the same, & people too often try to fulfill only one aspect.

Timesheets are useful when they reflect the reporting needs. However, if you're not reporting on the actual activity, then there is a disconnect. Either, you have to change what you are reporting, or you have to accept that the data you are reporting with is not real. That's a disconnect - & a sad fact.

Timesheets are painless when they can be done "automatically" as part of an existing process - preferably without the team member doing anything. This could be as simple as monitoring their keystrokes (big brother = no bother), but it is better if the team are clocking all of their time against tasks in an issue management system - & every activity must be in the system.

This allows you to perform reporting against what is really happening, as opposed what is supposed to be happening. This is relevance.

There are plenty of tools out there to do this type of tracking, & none of them have the word "timesheet" in them.

They do, however, all track time in minutes & hours. In modern agile processes, activities are not estimated in time, but in story points, & they are often prioritised by business value. Therefore, there is a cost - estimated effort - against each piece of functionality that provides business value. In a lean environment, if there is no business value, just don't do the task.
We use this estimated cost in planning. We also use measures like velocity to determine scheduling: the number of story points - & therefore value - that the team as a whole can produce within a sprint (a time period).

We seem to have most of the elements in place to estimate a financial cost for each unit of business value that is delivered as long as we can determine a tangible correlation between delivered functionality & ROI - in terms of market share, increased sales, the value of the IP, or share price.

How can we define that true value of each feature?

Look at the approach taken to determine story points - it comes from experience. The team - the experts who are doing the work & have been doing it - agree upon the most likely cost, using tools like planning poker & the team velocity. They rely on the fact that, over time, estimations even out & have lower variance through increased skill & practice. Most importantly, they don't estimate in man-days. Still, tracking in hours, & having two-week sprints, "works".

The equivalent must be true of business value points - looking back over what impact a feature has on the value of past releases of product, plus the appetite in the market (based on end-user interviews, A/B testing, prototyping, etc), a relative score (not dollars) could be developed that would vastly improve the input to planning product development & this would also contribute to the accountability of the process in a much more tangible way than timesheets that track activities.