2009/08/17
Following are some notes based on initial Grails experience in a 1 month greenfield web application project.
Getting started
This is where Grails is really good at. It provides tools to help you create initial application and generates initial scaffolding code. We found that for a team without any previous Groovy experience it took about 1-2 weeks to get into decent development speed.
IDE support
Eclipse is basically nothing more than a text editor and code browser even if using its Groovy plugin. IntelliJ is quite good with refactoring, highlighting, Grails plugins support etc. Unfortunately you can't run integration tests in any IDE which makes it very cumbersome to debug problems.
Presentation (MVC)
Grails offers some shortcuts here and there but when comparing it with Spring's annotation driven MVC it comes down to annotations vs coding conventions. So it is just a matter of personal preference. It is possible to generate controllers and views but resulting code contains a lot of duplication and therefor is only useful for getting started and needs to be refactored later.
Persistence
Grails ORM implementation (GORM) helps to avoid writing simple but common HQL queries. However if you need more advanced queries then you still have to handwrite them. For custom queries Grails provides static methods like executeQuery which are injected directly to domain entities. If someone tries to do this in Java code it is usually considered bad practice 
. OK, in Groovy you can mock static methods but it still feels a bit strange.
Plugins
Grails plugins make it really easy to integrate some 3rd party library e.g for security. Unfortunately most plugins are still in 0.x version so every now and then you may find that some quite typical functionality is simply missing.
Summary
Grails doesn't offer anything significant that couldn't be achieved with plain Spring, Hibernate and annotations in Java. However, Groovy code is much shorter than equal Java code. Also Grails seems to be more practical than many Java frameworks that sacrifice their simplicity for support of some additional rare use case. So if IDE support will be improved and framework/plugins become more mature Groovy and Grails will certainly be even stronger alternative to the Java stack mentioned above - at least for small web apps.
2009/08/27
I used to think that hours burndown is better that story points for tracking sprint progress. However now I think that hours are not so good at all.
First problem with hours is that it is easy to start tracking only implementation time ignoring acceptance testing or functional testing done by testers. We could of course track remaining time for implementation and testing separately for each story but then we had to spend even more time keeping our estimates up to date. In addition it doesn't really matter if we think we are 60%, 80% or 90% done - story either is done or is not done according to the definition agreed by the team.
Of course it is harder to get the story points burndown to be as nice looking as hours. But story points burndown shows clearly when we have either too big stories or we are pushing acceptance testing too much to the end of the sprint.