Managing Milestones and Web development Project

Question

I am trying to implement Trac+SVN. But am encountering a project management issue. To give you a background, most of my projects are related to web development (they go thru phases like design, programming, testing etc.).

Now I am implementing Trac for my projects. Now the problem is what should I place as milestones and tickets. For tickets how granular should I get? e.g. should I say Make X part of Y feature or Make Y feature only. The more tickets I make, the more time I spend making these tickets.

Also, for milestones, I have seen projects like CakePHP etc. When they use Trac, they set their milestones as version numbers (corresponding to tags in the SVN). Is that the best way?

So say I have a client whose final deadline is X date. Then I set my milestone as 1.0 with deadline as X. But then how do I track the project say weekly? Cause I don't want to realise one day before the release date that that too much is left. I want to have somehow weekly checks.

Also I want to take into account enhancements/bugs also as tickets and club them together as milestones.

Ive imagined something like 1.x.x where first x corresponds to group of feature enhancements while second x corresponds to bug fixes. Is there a better way? How do I manage weekly status in such a system?

Is there a standard way to do this? How do I go about it? Am totally confused.

Thank you.

Answer 1

Well, it depends. You didn't specify how big project, how many programmers will work, how often do you plan to deliver.

Stating that, here's how we use Trac on one big project spanning several years that consists of number of smaller subprojects.

• Milestones are defined as points where we have some features in subproject ready for delivery. First milestone in each subproject is usually the longest. We usually name milestones as "Subproject Name v0.01". Versions are just increments 0.01, 0.02, ... When we implement everything expected for subproject we mark last milestone as v1.00. Subsequent bug fixes go to milestone that we mark "Subproject Name - v1.00 - bugfix"

• Milestone description contains only list of new features or bug fixes. Documentation is written in wiki and in tickets.

• Trac Wiki usually have at least one page about new features that will be implemented in specific milestone. It is usually higher level description of expected behavior of application. Often, there are examples of expected results application should produce.

• Tickets contain detailed description of feature or bug that have to be implemented.

  • Bug reporting tickets contain description of bug and steps to reproduce (almost always).
  • Feature tickets contain detailed description of feature that must be implemented. One ticket contains work for up to 6 hours. When we plan work, we divide features to be in range from 1 - 6 hours of work. If we estimate that feature needs more time, than we split it in several tickets so each of them can fit in 1-6 hours of work. We picked 6 hours because we feel it is the top that we can estimate with error not bigger than 30% (meaning that this 6 hours estimate almost always can be done in range between 4-8 hours). Of course, there are exceptions from this stats. In our experience, main reason for wrong estimates is in bad specifications that we wrote. That, almost always, happens because we (developers) misunderstood business requirements of our users.

• There are few Trac plugins for estimating and time tracking. Check this page: http://trac.edgewall.org/wiki/TimeTracking . We use Timing And Estimation Plugin . You can enter estimated time for ticket and time spent working on ticket. Then you can get reports how much time you spent on tickets/milestones and how much time you need to finish.

After two years, we can pretty accurately estimate time needed to do some work. When we correctly understand users needs and requirements, we usually can deliver in promised timeframe. Currently, our stats show that we overestimate time needed for tickets for about 10%.

Answer 2

A small caveat up front: I have no idea about using Trac... or SVN. I think your milestones shouldn't be set by the version control / bug tracking system.

Typically milestones are just significant events in your project. They should be significant to all stake holders. The completion of a major deliverable is a milestone. The completion of a few features isn't. Sign off on all plans and contracts is a significant event, but the completion of 10 mockups isn't.

I tend to use the schedule and tasks for working with the team. Tick tasks off as they are done. To everyone else i just report on milestones. Are we going to make UAT by May 15th? Yes we are.

Since milestones are tools for reporting to sponsors and other stakeholders you should set them to be what they think is important. My sponsors will want to know when a certain core set of features is completed, so that is a milestone. They'll want to know when UAT is signed off so that is a milestone.

Set too few milestones and no one will know how you are progressing until the end. Set too many and the value will be lost.

There is no magic formula, but projects with hundreds of tasks and thousands of man hours may only have 4 milestones.

alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

Sorry this doesn't relate to Trac and SVN directly, but hopefully this gives you a rough idea on how milestones are generally used. Oh and apologies in advance for the overuse of Comic Sans... yuck.