HOW-TO: Prepare for your first Iteration (using VersionOne)

June 4th, 2006

How to begin? You have the idea. You have the team. Now you want to make sure you come off the starting block clean. A bad start can doom a project so the beginning is a very critical and delicate time. There are many ways to start a project and “best practices” will vary depending on your sitatuion.

This How-To is written for a project with the following characteristics:

The team is new to agile methodologies, but has buy-in to use an Agile methodology for this project
This is the first version of the product

I recommend spending three days preparing for the first iteration. In later iterations, you will find that by the time you get to the next iteration, much of the iteration prep has been already done as fallout of the prior iteration execution (giving you the ability to start the next iteration IMMEDIATELY after the prior one completes).

DAY 1: Setup project infrastructure

First up, prep VersionOne for the project. You can follow the guide I wrote earlier. If you don’t have a clear idea or restriction on the number of iterations, I recommend initially planning for 8 two week iterations. Keep in mind, most of the professionals out there will recommend 6, but 6 is bit tight for my tastes — I suppose it is the curmudgeon in me. Whatever the number you pick, fire up versionOne, and go to the planning Tab. IMPORTANT: Make sure your project is selected in the projects pane (if you don’t the iterations you are about to add will be added to the System project instead of the one you want).

Click on the Iteration Planning subtab, and then on Iteration Scheduling. Add all your iterations. At this point, I would just recommend calling them Iteration 1, Iteration 2, Iteration 3, etc. Later, as you see what stories you are putting in them, you can give them more descriptive names.

Ok, next up is setting up your source code control and a collaborative document repository. I will make it simple for you. Use subversion for your source code control, use a wiki as your document repository. I will make it even simpler. Go and create a “more developer” subversion account on cvsdude.org. This will support up to 12 developers and comes with Trac (which you can use as your project wiki). Furthermore, when code is checked in, emails are automatically sent to team members alerting them of project updates. I suppose you could setup a server to do all this for you, but for less than $30/month, all this is done for you and wouldn’t you rather be spending your time on your project than on maintaining your project infrastructure.

And why a wiki you ask? Why use that for your requirements, project operational instructions, designs, etc? I will give you three answers:

A wiki is VERY collaborative friendly. It invites participation and has built in revision control at the page level.
You DO NOT have to know how to organize your documents apriori. The wiki’s organization can change over time to fit the changing needs of the project.
A wiki is enabling, a MS-Word document is directing — yeh, this last one is highly subjective, but it’s my blog after all, so I get to do that from time to time.

Once you have your wiki operational, get your feet wet by creating a page describing the basic project operations. You are welcome to use the “Project Operations” I included below as a starting point.

If you decided to go with cvsdude and are using Eclipse as your IDE, you can follow the subversion plugin configuration guide I wrote up.

DAY 2: Select iteration 1 team, and brainstorm stories

It is important to start with a small team. When you first start there are a lot of unkowns and you want to be careful about a “too many cooks” problem at the start. Get a core of say, 5, for the first iteration. This will help you build a good team dynamic in the first iteration. You can ramp up team members with each successive iteration.

Gather your team up, and go to a conference room that has a computer, a network connection and a white board. Pick one person as a scribe. This person will enter in stories as you identify them. Now comes the toughest part: start describing what needs to be done in non-technical terms. Draw pictures of what you think the product will look like when its done. Talk through what the product will be like, from the user’s perspective when it is built. Read up the article on feature estimation at versionOne. It is a good write up. If you want to see an example of stories, check out the Iteration kick off posts for the Agenda Redux project. Notice how in the earlier iterations the stories are mediochre at best, but with each successive iteration, the stories get more and more about end-user functionality. That is because we learned as we went and applied that learning to our planning process.

You haven’t started your project yet, so there is a lot that you don’t know. So, in your brainstorming, start with what you know. What do you absolutely know that the end-user will need. Don’t worry if the stories are over reaching, under reaching, or too technical. Get the ideas out — you won’t have to worry about overplanning, because you are not going to spend more than this day on planning. Your goal is to “prime the pump” for your project.

Now, to add stories, your scribe will need to fire up VersionOne, and click on the planning tab.

Again, make sure you project is selected in the project pane. Select the “WorkItem Planning” sub-tab and then “Stories and Defects”. Now Select “Add Story”

Ok, so those are a lot of fields, huh? Fill in the title, and a short description. At this point, leave the rest blank. The rest of the fields will become quite useful, but at this point, just capture your ideas. Later, as you learn more while executing your iterations, you will know how to fill in these fields.

DAY 3: Select stories for iteration 1 and define tasks for those stories

Now we come to the toughest part, picking the stories for iteration 1. First off, as individuals, you know what you can accomplish in two weeks time. Keep that in mind as you select stories. Second, at the end of the two weeks, IT IS IMPERATIVE that you have an application to show. It can be ugly, patched together, and fragile. But you need something in place as a baseline. Keep this front and foremost as you select your stories. You see, this early in the project, your primary goal IS NOT building a product, BUT getting to the end of the iteration hitting most of your goals. Your goal is build a team dynamic that can set a set of two-week goals and accomplish those goals. If you do that, bit by bit, you will chip away your project in a predictable, robust fashion creating a product you will all be proud of.

Also, when planning the iteration, better to overshoot A LITTLE than undershoot. One of the skills you will need to learn is how to monitor and adjust the iteration as you go. It is perfectly acceptable to move the lower priority tasks and stories to later iterations in order to close out the iteration. What you don’t want to do is run out of requirements before you hit the end of the iteration.

So, with that in mind, gather up your team and head back to the conference room. If you can, get a projector for the computer so you can all see versionOne.

Fire up version one and select the Planning tab. Then select the Iteration Planning sub-tab, and then Iteration Scheduling.

For each story you have selected, click on the story and drag it onto Iteration 1. Now, edit each story and assign an owner. Ask each owner how long they think the story will take and enter that into the Estimate field. Now break and have each owner create tasks. They do this in Planning–>Work Item Planning–>Stories and Defect. Make sure to click on the “Show tasks and tests option”. To add a task, click on the “More…” link by each story. There is an “Add task” option there. I recommend that tasks should be no less than 0.25 days in length and no more than 2 days.
Now, gather back in the conference room and update the estimates on the stories so that they match the detailed estimates. Now, if you have 5 people on the team, the estimates should add up to somewhere between 55-60 days. Remember, you are trying to overshoot a little. If you are past that number, move one of the lower priority stories to the next iteration. If you are under that number add in another story.
Once you are done, write up an iteration kick-off message and post it onto a team blog, or on the team wiki.

You are now ready to begin your iteration. Good luck!

Here is the project operations page from my project wiki:

Project Operations

Iteration Prep

A couple of days prior to the start of the iteration, the home wiki page will be updated with an iteration prep message. This message will indicate what we are shooting for. Before the current iteration ends:

Review the iteration prep message AND add/edit it if you think it is wrong. If you don’t think an item belongs in the iteration, just note that (vs. removing it).
Update the prep message with the amount of time you think you will be able to spend on the next iteration.
Update the prep message indicating which items you are signing up to work on. You can pick an item someone else is working on — just make sure to coordinate with them when planning and executing.
For those items you signed up for, update the item with an estimate of how long you think it will take. You are free to move up or down an estimate someone else entered (just please put in an explanation).

Iterations start on Sundays. On Sunday, I will use the information in the prep message to assign stories to the iteration and assign primary owners to each story. By end of day monday, it would be very helpful if you:

If the story is shared and you are the primary owner, edit the story and fill in some detail in the description of the story.
If you are working on the story, add tasks with detail estimates for those items you are doing — or those items you know need done.

Daily Routine

Each day you work on the project:

Start by reviewing your tasks in the MyHome tab.
Fire up the project wiki, and click on the “Recent Changes” link. This is a quick view on what’s going on with the project. For a more detailed view, click on the Timeline tab.
Work on whatever tasks you have chosen to work on for the day. Update/add any wiki pages as required. If you discover an issue, add it to the project management tool — same goes for stories, defects, requirements, and tasks. Remember, this is collaborative — change is encouraged — just don’t delete.
If you need help, do one of two things — post a help request on the wiki OR if you need help from a specific person, Create a task in VersionOne and assign it to the person you need the help from.
At the end of the day, go back to MyHome and select tasks. For the tasks you worked on, update the effort column with the amount of effort you spent and hit apply. The units are days (where one day == 8 hours — so 2hrs = 0.25, 4hrs = 0.5, etc.). Update the To Do column with the amount of time you think is still left to do. If you worked on a task that isn’t in the project management tool, add the task. If there is no story to add the task to, add the story.