Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 becuase 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 moulded to add a process that will reduce defects and produce good code, then it simply isnt "agile". In the end the team voted down the proposal claiming that it wasnt "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 "wroking code" or "good working code"?

share|improve this question
    
FPA is? Function Point Analysis? –  Thomas Owens Jun 8 '11 at 11:12
    
i thought scrum is a part of agile .. am i wrong ?? arent scrum meetings a part of agile process ?? –  Ritwik G Jun 8 '11 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 '11 at 11:21
    
@Thomas Owens: thats right. FPA is Function Point Analysis. –  DPD Jun 8 '11 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 '11 at 12:53
show 1 more comment

1 Answer

up vote 3 down vote accepted

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.

share|improve this answer
    
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 '11 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 '11 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 '11 at 9:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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