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"?

  • FPA is? Function Point Analysis?
    – Thomas Owens
    Jun 8, 2011 at 11:12
  • i thought scrum is a part of agile .. am i wrong ?? arent scrum meetings a part of agile process ??
    – Chani
    Jun 8, 2011 at 11:17
  • @Scrooge: No, Scrum is a particular methodology that is part of the agile family. There are a lot of different agile methods, such as Crystal, XP, and the Agile Unified Process.
    – Thomas Owens
    Jun 8, 2011 at 11:21
  • @Thomas Owens: thats right. FPA is Function Point Analysis.
    – DPD
    Jun 8, 2011 at 11:51
  • Another question as I'm working on my answer: Why are you using FPA? Function points are a measure of functionality. When combined with time, it's a metric that shows productivity. Scrum already has measurements and metrics for this - user stories, story points, and velocity. It honestly sounds like an overall process problem to me.
    – Thomas Owens
    Jun 8, 2011 at 12:53

1 Answer 1


This is a classical case of a mislead SCRUM implementation. You (and your team) need to follow this basically from the point of break-down back to the changes that need to be made (remember: SCRUM is an adaptive process, the second half of the review meetings is supposed to be used to figure out how to make it work better in the next sprint(s)!).

The point-of-breakdown is clearly all the bugs raised by the GUI team. There is another point-of-breakdown in the fact that your code cannot be tested directly. Both of these point to insufficient story definition. This level of detail (length of text fields, etc.) does not have to be done up front, it can happen during the sprint, but it requires close interaction between the team members and the product owners (you DO have product owners, right?). If this interaction takes place, then no additional documentation is required. In the interaction does not take place, then you have a problem and the scrum master needs to step in.

Also, if your work cannot be associated with user stories, then the product owners are not doing their jobs properly.

I have used SCRUM for many years, and I am a certified SCRUM Master. I can tell you from experience, if you follow the basic principles, it works beautifully. But you have to follow ALL of them, not just the ones that suit you (you in this context means the entire scrum team including the product owners).

You don't need FPA, just fix your SCRUM process.

  • The issue is that the client defines stories only in terms of user input->expected behavior. There is no scope to define behaviour for my layer in this scenario. So you are suggesting that all layer behaviour be defined explicitly in the story. That seems like a good idea. But still, wouldnt you need a deeper analysis to note the implicit requirements that are a natural product of the explicitl stated requirements. or should these be stated in the user story before estimation?
    – DPD
    Jun 9, 2011 at 18:24
  • This is the normal way to write user stories, nothing wrong with that. However, as Mike Cohn put it once (I believe it was him): a user story is nothing but a reminder to have a conversation about this functionality. It is only fleshed out enough to allow estimation. Once you start implementation, you need to get input from the product owners about the details. If they don't care, then they can't complain about you making decisions of your own. If the results don't suit them, then they have to write more stories.
    – wolfgangsz
    Jun 9, 2011 at 19:03
  • That is exactly how we are doing it right now. We have a discussion about the details after the initial estimation (personally I feel it should be the other way round :-) but thats another story). I just note the details on paper, mail a brief memorandum) and proceed using that . I just felt that FPA would serve better for detailing and estimation.
    – DPD
    Jun 10, 2011 at 9:06
  • @DPD What you're describing isn't an "Agile problem", it's a "people problem". Either issues are being ignored in that discussion (What is the minimum text width for FIELD?), questions aren't being communicated throughout the sprint (For my GUI, what can I assume about length for FIELD?), or developers are making assumptions without consulting anyone (There's no way FIELD should be less than 4 characters, so we don't need to handle that case). This would be a great discussion during retrospective and should result in an experimental process change to see if these issues get better.
    – Chris G
    Jul 5, 2017 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.