Does SCRUM mean no more documentation?

I have embarked on a new adventure. I am sailing the waters of agile development, specifically scrum. Scrum is not an acronym. It comes from the rugby term.

My new environment is a fairly mature scrum environment. For an old waterfall hand like myself, it is a different beast. I could take the viewpoint that I have read from others in the database world and declare that agile doesn't work in a database environment. Instead, I'm having fun with it. This is a chance to learn a new way of doing something and I plan to give it my best shot.

Scrum, according to ScrumAlliance.org, is an agile software development framework that features development in short cycles called sprints. A sprint is typically 2-4 weeks. During each sprint, the developers work on a prioritized list of customer requirements called user stories. The benefits of scrum (to me anyway) are that the highest priorities (from a customer viewpoint) are completed first and you have regular deliverables on a regular schedule.

The first thing that jumped out at me as I started into my first sprint is the lack of documentation. I started my career with the US Department of Defense and have worked extensively with CMM. I am used to plenty of documentation. Scrum? No requirements, no high level or detailed designs. Not much of anything else as far as I can see.

User requirements are replaced with user stories. Each requirement becomes a user story. A user story is as simple as:

"When the application opens, it should reopen the last document used"

That's it. As I first got into this, I kind of freaked out over that. What the heck is that!?!?!?

From the scrum methodology, a user story is just a starter for a conversation. In scrum, the user will be involved throughout the entire development process. Basically, by accepting the user story, I (we) say that I (the team) commit to having that functionality added in a sprint.

It's costed as best we can and as we refine our knowledge, we refine the estimate.

This is huge. Two things: the user is constantly involved (eliminating delivery/acceptance surprises) and estimations are refined. This turns most project management on its head. We don't track how much time we have spent on something, we only track how much time we have left. If, during discussions with the customer, they ask for something that would take longer than the time remaining in the sprint, we can end it in this sprint and add it to a future sprint or the user can reprioritize to ensure they get the features most important to them. The end date of the sprint is never extended and you never add more developers.

We actually treat an estimate like it is an estimate. Gasp!

I kind of got off track with the documentation. I will pick up the above discussion in the future. For now, suffice it to say that no giant requirements documents are created.

No design documents either. Developers document their discussions with the customer in their own way (in our case on a wiki). That serves the developer as a guide. That is not a deliverable though. There is no approval process. If the developer does not understand what the user wants, the user will realize that very quickly as they are involved in the process daily.

Plus, we all know that design documents are out of date before we even start coding.

This is just the first of many entries that I plan on scrum and how agile development works for me. Have you used agile development? I'd love to hear your thoughts. Pluses and minuses. I'm especially interested in anyone using agile methodologies while doing database development.

Thanks,

LewisC