We use bugzilla to track bugs and feature requests, and we also require developers to write to a separate release notes should they finish coding a feature. Old fashion, I know.

One problem we have with the above arrangement, is that while it works great for software that we are already selling, it is completely useless when comes to track the progress of a new software development project. The reason is that at the point of developing new software, we don't,or rather, we can't, use bugzilla to trace the features simply because bugzilla is not suitable to represent the complicated intricacy of feature dependency ( To complete a new software application, there are just too many features to code and we just don't feel like putting them in bugzilla, and even if we did, we had no way of knowing which features depend on which, and we won't be able to get an accurate prediction of the shipping date anyway).

Then, our stakeholders will get concerned about our development progress ( or lack of) and start banging on the team lead ( yours truly)'s door on the estimates, which I can't answer because tragically, I also honestly don't quite know how far is the new application from completion.

How would you present your software development progress to your stakeholders?


3 Answers 3


Do it the Agile way: Demo early and demo often.

Nothing beats the visceral feeling of actually using it to give a feel for progress.


Disclaimer: I've never used Bugzilla before, so I'm unsure of its project management capabilities (although Bugzilla:Project Management with Bugzilla appears to look good).

This issue sounds like the result of a lack of discipline. You should be using project management software to plan and be accountable for your time and effort spent. Any project management software (I've been impressed with Jira and Redmine) has functionality to split tasks down to a level so you can give an accurate (~hours) estimate on each task.

From there, it's a case of being disciplined and filling out the task details. This will provide the an overview in the form of a gantt chart (Redmine) or a project burndown chart (Jira) which provides instantaneous evaluation on your project's progress.

At the end of the day, it's simply providing a time estimate (which is done by breaking tasks down to maximise accuracy), then as development starts, comparing progress against the initial (or revised) estimates.


Project management doesn't have to be incredibly fancy or require sophisticated tools, and KISS isn't a bad mantra if you don't have dedicated project managers. If you are developing new software, then you must at least have some kind of spec or list of features. Itemize and dump them into a spreadsheet along with maybe a time estimate, an expected start date, an expected delivery date, hours worked, and a status indicator (done, in-progress, not started). You can then manufacture generate whatever metrics you feel are appropriate to indicate project progress (such as a % completion based on number of estimated hours for completed items vs. total estimated hours). Generate a few graphs with bright colors, and everyone is happy.

A lot of PPM software can be overkill for small teams, tracking multiple projects, resource assignment, QC items, etc. etc. If all you really need is to create a status report, a spreadsheet does fine. "We've completed 92 of 127 features, and estimate we will be done coding and in testing two weeks ahead of schedule." Everyone claps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.