My team builds software for a living. We are really good at it and have worked together for many years. Recently I wanted to make some changes to our timesheet application to handle our project hierarchy. Here is how I went about it:
- Having access to the database diagram I whipped up an ERD (enterprise relational diagram) showing the new tables.
- Because I have done this stuff before, I also described the purpose of those fields, and where I wanted it to appear on the user interface.
- I sent this off to Jen to code.
So far so good. Jen then codes it and guess what. It was horrible, and she coded it exactly as I requested it. 100% accuracy of deliverable to spec and it was unusable.
So what did I do wrong ?
- All the time I spent describing the “what”, I spent no time describing the “how” and the “why”.
- I left no space for creativity on behalf of the programmer.
- To be honest I didn’t even have a good picture of how I would use the functionality so no wonder I could not describe it.
My do over?
This is the value of use cases. They describe in human terms how systems behave. When we refer to systems we mean the people, tools, data and processes required to achieve a specific business outcome. At its simplest it is a script for, what is probably, the most boring play ever.
A use case consists of:
- An Actor (in this case me)
- A goal
- A set of steps
- Alternate flows, preconditions etc we’ll ignore right now.
Rather than tell Jen to put a button here, table there and field somewhere else, I should have described the requirement as follows:
Use Case: Maintaining a project hierarchy
Actor: Administrator
Basic Flow:
- After clicking on the project hierarchy link, the administrator will be presented with a graphical representation of project categories, groups and projects. (Every project will be represented)
- The Actor will be able to drag and drop projects into groups or categories (a project can be part of a category or a group)……
What is happening as I do this is that I am articulating an outcome and imagining myself doing it. Hopefully this is then the basis for a conversation over the implementation of the feature set, not the purpose. It also makes for easy testing.
All in all focussing on the story and not the technical requirements would have been more collaborative and produced a higher quality output all for less work. Not bad huh ?
Author
