Recently, I was coaching a client who was embarking on a new project. The project team was not formed, but key stakeholders were planning what the projected needed to be. In Agile (specifically our Lean/Scrum/XP mix), we have iteration planning, release planning, and project planning. This client is doing project planning, and the question came up about how to write stories for the project. After all, we have to know the entire scope of the project in order to plan it, right? Historical trends tell us that even if we think we know the full scope of the project, we'll be wrong, so I helped this client identify the key components of the project to formulate the high-level project scope.
If you like this post, you can subscribe to my feed at http://feeds.feedburner.com/jeffreypalermo
After we understood what the high-level requirements of the new software would be, we did a prioritization and created a backlog that we hoped would turn into a short-term first release. With this rough release plan in mind, we did a small story-writing workshop. We first wrote some stories together and then broke off into pairs to complete the remaining stories. We concentrated on only the first release because that release contained the highest priority items (from the prioritized backlog). We knew we were working on the highest value items first.
Here is an example of a story (adapted from CodeCampServer as a realistic example):
"As an organizer I want to have a place to enter maps and driving
directions so that the attendees can find the event."
First, we have the persona of the organizer. The organizer is in charge of the event and is doing the planning. Often it's helpful to give him a name. We'll call him Oscar the organizer. Then, we can discuss what Oscar cares about to get a feel for how he'll use the system.
Your first thought is that this isn't enough detail to formulate a release plan, and you're right, but it's a placeholder for a conversation with the team that's going to make it happen. I think a requirements document is also necessary. Writing stories doesn't take away the need to think about some level of detail while planning the overall project. After all, when estimating the release, it's necessary to know if driving directions merely means a link to Google Maps or if it means an interactive mapping system built into the application.
Be careful about adding too much detail to the story because then people won't read it. If every story is a full page, it's too long. Story can act as headers in a requirements document, however, if you prefer to organize it that way.
Ok, buddy, but how will we know what the acceptance conditions are? You need to know the high-level acceptance conditions, but I caution against laboring too much on small details of each story before the project has even kicked off. You'll paralyze yourself with analysis. Define just enough detail to move to the next step, release planning. By the time you move through iteration planning, and the team has asked all their questions, all the details will be fleshed out, and the team can turn the story into working software.
Finally, get help from someone with Agile experience. I've seen many people who have studies Lean/Scrum/XP struggle to move from use cases to stories with only academic knowledge. There is no replacement for apprenticeship.