Current Articles | RSS Feed RSS Feed

The only 3 Milestones you will ever need

Posted by Andy Singleton on Thu, Feb 21, 2008 @ 01:03 PM
Digg digg it | Reddit reddit | del.icio.us del.icio.us | StumbleUpon StumbleUpon 

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.

Tags: 

COMMENTS

Yes, I agree a lot with this post. I name these "Current Upgrade", "Next Upgrade", and "Future Upgrade" for my projects.
We have used one more though that I believe has merit, a "Request" milestone.
I use that milestone to file all incoming requests to the system that are not entered by someone involved with the project. Users of your software often need to file tickets but I want to complicate the entry by having them pick a development milestone for me.
When I review the ticket, I'll reassign it to one of the 3 development milestones. Often an edit is required anyway to correct and comment on the original issue.

posted @ Sunday, March 09, 2008 8:17 PM by webflint


Just to elaborate, in the PM systems i have used before I have always had the need to batch edit or promote a group of tasks or milestone to another.
For example, when I complete the Current Upgrade, I have created a new Milestone with a descriptive title, say "Version 1.0YYYYMMDD", I then move all tasks, tickets in the CURRENT UPGRADE milestone that have been fixed and closed to this new milestone.
QA then begins on the "Version 1.0YYYYMMDD" milestone and all issues from my "Next Upgrade" milestone get moved into the "Current Upgrade" milestone.
When the QA is complete, the "Version 1.0YYYYMMDD" milestone is archived. The items that existed in it after being verified become the Release Notes for the new build.

posted @ Sunday, March 09, 2008 8:24 PM by webflint


Can you guys explain to me what is the purpose of the milestones?
I thought it's primary purpose was to define the project stages, ie:
Milestone1: Put up database
Milestone2: Create gui
Milestone3: Create websites
...
With this I can have many different milestones - and not only three.

posted @ Friday, March 21, 2008 1:40 PM by dopey


Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics

Receive email when someone replies.

Blog Navigator

Navigate By : 
[Article Index]

Subscribe by Email

Your email:

About This Blog

Accelerating Software Development with Agile, open-source style processes, distributed teams, on-demand teams, new product launches, Web 2.0 strategies, startups.  Author Andy Singleton builds new products fast.

About Us

Assembla offers services for building software with agile, distributed teams.