I am currently working in an Agile + SCRUM based project. I work on a lower level module. This leads to a peculiar problem. The work I do cannot be directly associated with a user story many times. Since I cannot relate a user story directly to my work I often face the problem that my requirements are unclear. Also I tend to "miss out" a few things which only become clear to me late in the sprint. And my layers work cannot be tested directly.
On a similar note our GUI team was generating a lot of bugs due to missing out minor implicit requirements. For instance, the text field width was less than anticipated, etc.
I had used FPA before in another project and I think it is a good way to break down requirements to the tiny atomic details, clarify the minor points and then build your software using the points as a checklist. I really felt that it would benefit our project and my layer in particular. I suggested it in my team meeting bit it was turned down because of the documentation involved. The "wise guy's" rationale: FPA is documentation-heavy and Agile frowns on heavy documentation. I argued that Agile is about producing good products and if an Agile process cannot be molded to add a process that will reduce defects and produce good code, then it simply isn't "agile". In the end the team voted down the proposal claiming that it wasn't "Agile". however I suspect the reason was more likely to be laziness.
Is FPA really incompatible with Agile due to the amount of documentation involved? What about the lofty aims of the Agile Manifesto? Is it just "working code" or "good working code"?