A Project Walk Through – Defining User Stories

One of the things that I’ve learned is that you shouldn’t start development until you’re ready. You shouldn’t start until you have a good idea of what you are building. You shouldn’t start until you have some reasonable idea of how long it’s going to take. You need to make sure the information is organized and that everyone knows what they’re supposed to be working on.

I think Agile has gotten a bad reputation in some cases because it’s been used as a cover for disorganized teams with no process (I’ve been on one of those teams). Agile software development doesn’t mean anything goes software development. If the stakeholder asks “Where are we on the project?” and the answer is “Oh it’s agile, you wouldn’t understand.” then something is wrong.

I want to attempt to do a walk through of an imaginary project that gives some insight into situations that others may come across in their own projects. This will take me several posts, so bear with me.

A school district is planning an event for teachers where they can signup for different workshops on various topics. A development team has been asked to write a simple application to manage coordinating the workshops and the registrants.

This seems like a simple enough application and  a developer might think they know how it should work. Most of the time they would be wrong unless they were the stakeholder as well as the developer. The stakeholder has a lot of information tied up in their brain that developers don’t know about. We all take for granted the information we keep in our heads and it’s often difficult to present detailed information in a format that is easily understandable to a person that has no background on the particular subject. Even if it’s written  down in great detail, someone has to tear it apart, piece by piece and rebuild it into an understanding of the desired goal. Misinterpretation is often the result. To me, understanding requirements is one of the most challenging aspects of software development. Agile methodologies accepts a level of misinterpretation and addresses it by constantly challenging understanding through communication and reevaluation. You can’t have Agile without good communication.

At this point, it would be a mistake to jump right into coding because we haven’t talked about the details of what we’re building and we don’t have a good way to estimate how long it will take. If the event is in three months and development will end up taking six, then it may not be worth the effort to spend three months developing something we can’t use.

The stakeholders have heard a lot of buzz around agile software development and agree that it’s the way to go. They go off in a room for a couple of days and then emerge with a set of specifications written on index cards.

Unless the stakeholders have had experience writing user stories, it would probably be a mistake to start development at this point. More than likely, they have written waterfall type specifications and just put them on index cards and this just doesn’t work (been there, tried that). A possible example of a story coming out of this session might be:

A workshop can have a name, location, and a start date and end date.

The problem with this sort of story is that it doesn’t put the information into a context that helps us to understand how it fits into the system. This information is indeed valuable, but it doesn’t belong in that initial story. The story needs to give us just enough information so that we can quickly look at them and understand the feature and the business value.  Dan North’s post What’s in a Story?, explains a BDD approach to defining stories, which I’m currently using on my projects. Dan implies that acceptance scenarios are a part of a story, but I like to think of them as a separate deliverable because you don’t necessarily have to have that much detail up front. I’ll post more on this later.

Writing good stories takes a lot of practice and there will be a lot of questions. Some may be:

• What goes in a story? – See Dan’s post.
  • How big should a story be?  – Keep them as short.
    • How specific should a story be? – Start out general. You can always split a story later into more specific stories.
      • Where do the business rules of a story go? – In Scenarios. See Dan’s post.
        • Can I have stories that depend on each other? – Sure. Some features depend on other features.
          • Can I create non feature related stories (like coding framework)? – Sure. But you probably won’t have much or any acceptance scenarios.</ul>

            The stakeholders go back into a room with a story writing coach and this time they emerge with a set of user stories.

            As an Event Coordinator
            I want to enter event information
            So that it can be published online in order to attract potential registrants

            As an Event Coordinator
            I want to define workshops for an event
            So that event registrants can signup to attend those workshops

            As an Event Coordinator
            I want to define available rooms for an event
            So that workshops may be scheduled in those rooms

            As an Event Coordinator
            I want to schedule workshops in available rooms
            So that I can be sure that two workshops don’t occur in the same room at the same time

            …

          These stories are much better. They are short and have a role, feature, and benefit. A person can read through them quickly without being overwhelmed. Once estimates have been placed on the stories, someone will have to go and prioritize them and you don’t want them to have to read a whole paragraph to understand the story. There is enough there to start a conversation and talk about some details so that the developers can come up with a rough estimate. Some of these stories may be too big to fit into a single iteration, but you shouldn’t care about that right now. You can always split them later. For now, we need a high level view of our goal and we can always refine it later when we plan an iteration. If a story seems too big to estimate, then go ahead and split it now.

          In order to get a rough estimate on approximately how long the project will take, the team meets and has a Release Planning Meeting. The team goes through each story and gives them a point estimate.

          In this meeting, the goal is to educate the developers just enough on each story so that it can be given a general estimate. You can’t make estimates that are more accurate than the information presented, so there’s not much point in estimating in terms of time. By estimating in terms of points (size) you can later determine the unit of time that relates to a story point. The key is to estimate consistently and estimate the stories relative to each other. If a story is twice as hard as another story, it should have twice the estimate.

          Initially, to get a rough estimate for the completion of the whole project, you have to take an educated guess of how many story points you will be able to complete within a given iteration. This will be your initial velocity. If you have 1000 points to complete, your iterations are one month long and you can do 100 points per iteration, then you can estimate that you have 10 months of work. You may find that you will not have everything ready by a particular date, but you may have enough completed at an earlier date which will provide enough value to release. Remember this is a educated guess that needs to be refined as the project progresses. You have to do a couple of iterations before you really know your true velocity.

          The team makes an educated guess for the initial velocity and the stakeholders start prioritizing the stories into iterations. There is enough time for three iterations before the event and the estimates show that it will take six iterations to complete everything. It is obvious that everything cannot be completed by the deadline of the event, but it has been determined that there will be enough value coded at the end of the third iteration to have a release. Release 1 will only contain enough features to manage scheduling workshops.

          I’ll continue with the first iteration in a future post. Any thoughts, comments or questions on what I have so far are welcome.</p>

          Technorati Tags: User Stories,BDD