The only 3 Milestones you will ever need
Posted by Andy Singleton on Thu, Feb 21, 2008 @ 01:03 PM
I have posted articles that suggests ways to do roadmapping, in which you prioritize the things that you want to do into a series of releases, iterations, or milestones. We call them Milestones in our system. This is a nice tool for showing people what you want to do. But, you can simplify the job. My own technical lead reminded me of that when he recently reorganize our Assembla.com tickets. You actually only need three milestones to get all of your work done.
The agile process depends on scheduling releases, iterations, or milestones. The process is simple. You select a set of tickets that describe tasks and features you want to work on for the next milestone - the stuff that is most important. Then you finish as many of the tickets in that list as you can, and release. Then you take the leftover tickets, select some additional work, and start working toward a new milestone.
Here are the milestones you need to set up:
1) The release you are working on
You need this release because it tells your team what to work on.
2) The next release
Scrum teams often use only two milestones - the current iteration, and the backlog (unplanned). They don't bother to sort the backlog until they are ready to work on it. So, this proves that you actually only need TWO milestones to do your work.
However, this causes a political problem. There are always people who will argue that their requests need to be included in the current milestone. They are afraid that if a request doesn't make the cut, and gets thrown into the big backlog list, they will never get it. They apply pressure to hold or expand the release until those requests are finished. The releases don't go out on time and the process becomes less agile. You can relieve the pressure and get the release out by proving that the requests that don't make it are only moving to the next release. Before you have any discussions about what goes into the current release, I recommend setting up a next release where you can move contested tickets.
3) Backlog or Unplanned
This is where you put ALL the things that you want to do, everything. It can include small requests, ibug reports, ideas, use cases, and complete requirements. Someone will need to go through and remove duplicates periodically. If you make sure to include everything, you won't forget anything.. And, it makes people feel good about your process to see that you are tracking their requests. They are more likely to support the very rigorous and selective prioritization that you apply to selecting tasks for the current release.