Agile Workshop

User Stories Applied with Mike Cohn

Last week I attended a 2-day workshop with Mike Cohn. Mike is the author of User Stories Applied. He is the founder of Mountain Goat Software and is a leader in the area of Agile methodologies.

The first day of the workshop focused on User Stories. As I wrote before, user stories are used as a tool for defining the tasks to be completed in an agile project. Typically, user stories are written from the perspective of a user of the software. For example, a user story might read like this:

As a bank teller, I would like to be able to look up a customer’s account information by entering their account number.

This user story is then written on a note card. The user stories for the project are created in a user story workshop. The workshop will typically be attended by the project sponsor, developers, and some users.

The workshop included several story writing exercises. The advantage of user stories is that they are smaller and easier to read than a large requirements document. User stories can be posted on a wall so they are easy for everybody involved to see and track. This is not possible with a large requirements document. Also, user stories are flexible, allowing for changing requirements as the project progresses. This is advantageous since features and priorities often change during the development of the project.

The second day of the workshop focused on estimating and planning agile projects. The content corresponds to Mike’s upcoming book on the subject. I have some experience in estimating a project in my last project, during which we used the agile methodology. Estimating user stories is done by deciding upon either a time or magnitude value to each user story. For example, the user story above about the bank teller might be estimated as an 8. What that 8 means is up to the participants. It might mean 8 days of “ideal engineering time” (which differs from elapsed time, of course). Magnitude could also be used to define a measure of work involved for each task.

Everybody involved in the project should also be involved in estimating so that there is a consensus. Once all of the user stories are estimated, a plan can be developed.

The crux of agile development (and any XP methodology) is iterative deployment. In this case, an iteration time is defined. This can be 30 days, 2 weeks or whatever makes sense for the project. The project manager then must determine how much each developer might accomplish in one iteration. Here’s an example:

There are a total of 10 users stories that total about 38 story points or “ideal engineering days” of work. There are two developers on the project. We determine that each developer can complete about 70% of an ideal engineering day in a work day. (we must account for meetings, interruptions, etc). Doing the calculations, we can determine that based on this first run of the estimate, it might take about 28 days to complete the project. (38 days of work * 8 hours = 304 hours. At 70%, each developer does about 5.6 hours of work each day. For one developer, it would take 55 days to work 304 hours, divide by 2 for two developers).

If we use 2 week iterations, we know that the two developers can complete about 14 story points per iteration. We then must divide the user stories based on priority and estimates into iterations. The user stories must not exceed 14 story points per iteration. To complete the iteration, the completed work is released and tested.

If any of the estimates were inaccurate, the remaining estimates and iteration plans are re-evaluated. This happens after each iteration. As the project progresses, the estimates become more and more accurate.

As the project progresses, there are standard reporting charts that can be used to help track status. Of course, an agile project will inevitably include features that are added or removed throughout the project, so the reports should accurately account for that.

The 2 day workshop was very beneficial for getting a general understanding of working with an agile methodology. One benefit of agile development is that it is very flexible, allowing organizations to ease into it a little bit at a time. And of course, my knowledge will only increase as I get more experience. I’m looking forward to working through more agile projects in the future.