Agile Anti-Patterns – Addressing Failure Driven Development

This shouldn't be your problem.

Capitalisation of costs is your company CFO and/or accountant's problem. The rules vary in different jurisdictions. The accounting guys are the experts and should be capitalising costs according to the relevant accounting rules.

At most, they may need to ask you for some supporting information (e.g. of the 5,000 developer hours worked this quarter, can you estimate what % was on new software development or enhancement of existing software assets?). But it's up to them to ask you the right question.

If you are doing mostly new software development in a product that your company sells or intends to sell (i.e. the product counts as an intangible asset which returns future economic benefits) then it's perfectly possible to capitalise 100% of development costs. Also some countries have special incentives for R&D investment which is possible your software development work may qualify for.

The software development methodology you use is irrelevant, the only thing that is likely to matter is having some way of categorising which costs were spent on capitalizable projects or assets. But the same problem applies to waterfall development!

But for goodness sake, let the accountants sort this all out. You don't expect the CFO to write code, do you?

You're missing the point of agile a little bit. What you are calling a user story, I see as at least six: one bare-bones search, and one for each of your bullet points. By all means, make enough plans to avoid painting yourself into a corner that's going to be expensive to get out of, but the whole idea is that you provide the minimum needed to deliver some value, and do it quickly enough to get rapid feedback.

When you divide a story up like that, it not only makes it easier to estimate, it allows the product owner to prioritize in a more fine-grained manner. Certainly they like the ability to sort the search results, but maybe it's not as important as another item on the backlog that's completely unrelated to search.

Also, on the idea of programmers needing everything specified, try to look at it from the customer's point of view. A lot of times, it's like you're going in to buy a car, and the salesman is asking what color you want for the windshield wiper knob. A lot of details we might find important are completely irrelevant from a customer point of view. I've worked where requirements are highly over-specified, and trust me, it is not very fun. The kind of latitude you're complaining about, a lot of programmers would love to have.