One of my project teams was having a sprint planning meeting earlier this week. They were having a consulting expert working with them this sprint to develop a web service for their use.

“Have you worked with user stories before?” the project manager asked. “We’ll need you to give us a story point estimate for the work you’re going to do for us.”

I chimed in at this point. “Remember, story points are relative estimates of complexity. If our colleagues here are only doing one story for the project, then their story point estimate can’t really be relative to anything else they’re doing for us: they’re not doing anything else.”

This points out one of the things that I think is so tricky about agile projects. If you forget why you’re doing something, or worse yet if you don’t understand why you’re doing something, then you’re likely to do it at the wrong time.  In this case, the project manager did know why we estimated story points for stories, but he’d forgotten the why, and was operating a bit on auto-pilot: the team needed to provide story point estimates for their work, and he’d momentarily lost track of why.

Agile’s lots of common sense things like this, but if you forget what your goal is, and fall back on patterns of behavior, you can do the wrong thing.



Last week, I posted about our recent success at getting DBUnit working with an in-memory HSQLDB database,  which allows us to more thoroughly test data access objects (DAOs). Further work with that solution has unearthed some rather frustrating problems unfortunately. Read more



Unit testing software tends to break down at the boundaries of a system.  It’s difficult to test the graphical user interfaces (although with some of the new technologies like Selenium, testing browser-based GUIs is easier…) and the database access. I’ll save the UI for another time, today’s topic is the database access.

[Update – Read Some unfortunate behavior in DBUnit for important gotchas in this approach]
Read more


WP Themes