Agile Product Management
A place for product managers to learn and share tips on working with agile development teams
Question
I am in the midst of putting together some internal documents on where we stand with our adoption of Agile. We have recently talked about incorporating the idea of "Iteration Zero" at the start of a project.
What are the practical differences between Release Planning and Iteration Zero?
One thing I see is that the Iteration Zero's duration is time boxed as with every other iteration. That's probably a more practical approach since things need to get mulled about, researched, set-up and discussed before too much work gets going.
I guess I'm seeing the Release Planning effort being a set of well-defined meetings but really being focused on discussing the product owner's view on prioritization and a first round at estimating in points.
Any thoughts?
Comments
I think you are right that a key element of iteration 0 is that it is a short, timeboxed iteration.
I often think of Iteration 0 as a way of doing some pre-project prep without getting stuck in analysis paralysis or a never-ending waiting-to-begin phase. I also tend to think of it as having a product owner side and a technical side. For the first, the PO is creating an initial backlog, ranking it, and getting enough detail for the highest-ranked items to support the initial sprint planning. For the technical side, the team is setting up environments and beginning to understand what the project is.
Deliverables for Iteration 0 should be as clear as for any other iteration, with clear acceptance criteria and definition of done.
Often one result of the iteration is that we begin to have a starting velocity for the team.
Release planning, in contrast, is a single planning event (although there might be plenty of prep for that). On a new project, it is often not very helpful to do release planning right away....You first need to give the team a chance to determine its velocity so that release planning is meaningful. It might help to wait for three iterations. That way, you can use that velocity to plot stories across iterations to see what the team might accomplish in the release timebox.
Reply to this Comment
Ronica - Thanks for the comment. It is quite appropriate that you replied since I've been studying your article "Writing a Great User Story" recently (which created a few other questions for me that I'm hoping Marc C can clarify.) Back to this topic.
Some direct questions:
1. SHould iteration zero be the same duration as the other sprints? We are thinking of 3 week sprints for one and beyond. Is it acceptable to have ZERO be, let's say, two weeks if that's what we feel is appropriate?
2. I was puzzled by your comment about not doing Release planning right away. Are you saying that you "just" jump into the iterations - with appropriate planning for the iteration - and then have a Release Planning session later on?
It seems to me that Release Planning also has merit as a project kick-off vehicle to layout the vision, the makeup of the team, prioritizing and conversing about the user stories. So is the "later on" idea you laid out more of an "update" to the Release Planning with more informed sizing estimates?
3. You implied that Iteration Zero can give you a starting velocity for the team. My understanding is that iteration zero is much more about planning, meetings, and modeling types of activities. These are so very different from actual development I"m wondering if you really can get a useful velocity picture since the activities are so different.
Looking forward to this ongoing discussion!!
Reply to this Comment
I often do a shorter iteration zero than the other iterations, maybe just one week. It should be as short as you can stand, so the team can get into producing business value as soon as possible. Some people confuse iteration zero with an analysis phase in a more traditional project, but really the goal is to get just enough done that the first iteration can be reasonable. Lay out a basic backlog, define acceptance criteria for the first few stories, set up your workstations, source control, and build machines, and head into iteration planning. I wouldn't count on a very good starting velocity, but at least the team will get a sense of of how much time they can spend on the project.
For most projects, if you spend an hour or two laying out the backlog, you can quickly figure out a couple of stories that represent the most basic part of your project, that you know you're going to need. Often the team can start work on these stories without understanding the whole project in detail. For example, in my current project we knew we were going to organize our tests into folders, so in the very first iteration we were able to implement the data structure and web services interface, even without understanding all of the details of how they were going to be used.
In running a real iteration, you learn a lot very quickly. You might learn that your lead developer doesn't actually have any time to dedicate to your project because she's working on 5 other things. You might learn that there are technical limitations of your architecture that will get in your way. You might learn that keeping the developers in Atlanta in sync with the developers in Bangalore is really tricky if they're working on the same things at the same time. You'll definitely get a good idea of how much the team can get done in 2 weeks.
If you run a few iterations based on your best guess of the highest priority work, you can go into Release Planning with enough information to produce a reasonable plan. If you jump right into release planning without trying an iteration, you'll probably be working with poor assumuptions and you'll need to redo Release Planning later. This isn't necessarily bad, but it's usually more expensive.
Reply to this Comment