|Version 10 (modified by anonymous, 7 years ago) (diff)|
Scrum iteration planning plugin
This plugin provides some basic project management essentials to do Scrum-style iteration planning in an Agile project.
The plugin is a sort of Trac adaptation of the concepts in Agile Estimating and Planning by Mike Cohn
I did most of the development on Windows/Apache/Postgres 8.1.4/Trac 0.11. I really have no idea if the SQL will work on any other backend. These days I really do not have the time to maintain the code. Does anybody want to volunteer? Let me know
The upgrade procedure creates a column called 'started' in the milestone table, some SQL views and functions, and some Trac reports. No external scripts are needed to collect iteration statistics. Everything is done with SQL queries.
The plugin needs two custom ticket fields, so the following must be added to the trac.ini file of the environment:
[ticket-custom] estimatedwork = text estimatedwork.label = Estimated Work estimatedwork.order = 1 estimatedwork.value = 0 workdone = text workdone.label = Work done workdone.order = 2 workdone.value = 0
I then backported to Trac 0.10. The backport changes are actually quite trivial. In fact I left the 0.11 code commented out and ready to kick in. I just didn't feel like creating and maintaining two different branches.
I couldn't find any way to make the Python setup utilities also build the Java applet, so I had to use a trivial Makefile. So, to build, you should just run [n]make in the plugin root directory. make install should deploy it. As long as Python and javac are in your path, it should work. I did try to run Cygwin GNU make 3.80 on it, and it seems the Java target build statements upset the shell. Couldn't figure out why :-( Note: for compiling under *NIX, or Cygwin modify the setting of the classpath separator (in the Makefile) from ";" to a ":" as in
javac -Xlint:deprecation -classpath jfreechart-1.0.3.jar:jcommon -1.0.6.jar ProjectCharts.java && \
If you have any issues, create a new ticket.
Download the zipped source from here.
Instead of entering some value that is then added to the workdone counter for a specific ticket, users enter the actual new value. So if for a ticket the current number of workdone hours (or whichever tracking unit you chose for your project) is 7, and an engineer has just done 3 more hours, he should simply input 10 and submit.
The iteration burnup chart simply groups all the tickets that currently belong to the selected milestone, and starts plotting all changes to the the sums of their work estimated and done values. The iteration period is marked by an interval marker. If work has done on the tickets outside of the iteration period, then some points will be plotted outside the marked area.