In my opinion, there is a fine balance between too many EJBs, and too many methods in an EJB.
I try to use 2 rules from OO design to define the granularity of EJBs. The rules seem to fit well in the EJB model.
Rule 1) Coherency
Rule 2) Responsibility.
Rule 1 states that you do only the things that you are responsible for.
Rule 2 states that you do all that you are responsible for.
As an example, if you have a stock analysis program that has a Stock EJB, you would expose methods on the EJB that set the price, last trading volume, and other data pieces related to stocks. This covers rule 1. But, you would not have a method called addToPortfolio(String portfolioName) in the stock EJB. This would violate rule 2. The second method would belong in the Portfolio EJB.
If you follow these rules, your application definition and use cases will drive the granularity of your EJBs.
Mark