David and Katherine Goodwin

Here at PalePurple, we're always looking for ways to make ourselves more organised and more efficient. Recently David's been blogging about our efforts on the code side, with our framework code, and our new common directory structure.

While we're pretty happy with the way we work in most cases, we are aware that we can improve our organisation on various fronts. One of these is tracking our progress against requirements. We are, quite often, guilty of keeping requirements - or at least changes to initial requirements - in our heads. That worked pretty well when there were just the two of us, but we're now up to essentially 4 people, and who knows if and when that might go up. This means that now is the time to introduce better processes for recording requirements and changes to them - before we make a cock-up somewhere.

We've decided to start with recording the requirements for one particular customer. They started out with a small, fairly simple system that has grown as they have seen it develop, and have been inspired by what they've seen. So we've got an initial spec, and a load of quotes and tickets as we've added more features. What we don't have is any easy to read reference about what features are supposed to be there, and who is supposed to be allowed to do them, which makes our developers have to keep asking me for confirmation, and makes us have to keep sitting down and thinking about who is allowed to do what when we add new stuff. Essentially, there's too much to keep in our heads, and I don't want to sit down and write an updated spec, as that won't be really easy to work off.

The question now is whether to use the agile practice of User Stories or UML Use Cases. For this particular customer, I wish I had got them to sit down and write user stories with me at the beginning of the project, as it would have saved some confusion we've encountered along the way. However, at this point we've got lots of information from them, and I think its all there, spread between specs, emails and meeting notes. I sat down and started to write user stories for this, but encountered a few problems. Writing user stories for things that have already been implemented seems pointless, but I do want to record the requirement for reference - to make sure we stick to it as the application grows and changes. Also, I was struggling to get a level of detail in them that felt right. Lastly, I wasn't sure how to (or whether to) relate these to trac tickets that are our basic units of work.

So I thought about use cases. They would definitely represent one of our current problems better - if we're focusing on actors in the system, we can more easily relate them to the system roles, and have a good definition of what they should be allowed to do.

I'm going to keep documenting this as we try to produce our documentation over the next week, but I'd be interested in people's opinions on this. I've written and used use cases a couple of times before, quite successfully, but have never managed it with user stories. Do people agree that user stories work better at the beginning of the project?

Anyway, I'm off to sketch out initial use cases now, so we'll see how it goes.

Technorati Tags: