March 20, 2004
As someone who has spent quite a bit of time performing the role of Iteration Manager (IM) in an Agile development team, I'm quite keen to try anything that purports to make the tedious nature of this role more lightweight. For that reason, my team is currently trialing XPlanner for an iteration to see how it stacks up against our current Excel spreadsheet-based time recording system.
XPlanner is an open source, Web-based tool for helping the planning, recording and tracking of an Agile project.
For context, here's what we currently do in Excel, along with approximate costs in time:
- Each day, the developers submit their hours to the IM (5 minutes/developer/day).
Note: this usually happens the following morning for the previous day.
- The IM updates the spreadsheet appropriately (the spreadsheet maintains card and iteration totals) (30 minutes/day)
- Each day, the IM transfers a summary view of the iteration's status to our BVC (30 minutes/day)
- Each day, the IM sends a brief (email) status report to our off site customer. This is basically a list of work in progress cards, a list of completed cards, plus a warning flag should new cards been needed for the iteration. (15 minutes/day)
- Prior to each iteration's close meeting, the IM creates a few simple summaries of our actual data (i.e., cards completed, estimates versus actuals, non-project time, project non-development time, etc) and pops these into a Powerpoint presentation (60 minutes / iteration)
- The IM resets the spreadsheet for the next iteration (30 minutes / iteration)
Total effort / iteration (assuming 6 developers and 10 day iteration) : 21.5 hours
So to make XPlanner a viable alternative, it needs to support these tasks with less total effort than our current approach.
XPlanner is a doddle to install, requiring merely the presence of a servlet engine and RDBMS. I managed to get XPlanner, Tomcat and MySQL installed/configured on a new box in 30 minutes using the simple installation instructions. Basically, you just need to configure an appropriate datasource (a MySQL one comes pre-configured), build the WAR (using the supplled Ant task) and drop it into the deployment directory for your servlet container.
Note: to perform the installation, you'll also need a modern JVM (i.e., 1.4.1 or greater) plus a compatible version of Ant.
From there, just browse to
http://<machinename>:<servlet container port>/xplanner and you should be laughing.
Once installed, it's simply a matter of creating an initial project and iteration and a bunch of user logins and Bob's your mother's brother.
A couple of initial points to note from this data initialization step:
- XPlanner has no concept of Releases. Iterations live directly within projects.
- Users are not assigned project roles (e.g., developer, customer, etc.) but XPlanner roles (viewer, editor and admin). This means you usually need to create user logins for every customer assigned to a card.
Once the project and iteration have been created, it's down to the daily grind of adding new cards/tasks, estimating the work and updating the hours against these items.
At this point, it became clear to us that there wasn't any documentation on how to actually "use" XPlanner, and although it's bleedingly obvious the majority of the time, it did take us a little while to work out how actual hours were recorded (i.e., if you assign hours to a task for a pair, then that amount of hours appear in both the individual developers' timesheets, and the same amount is recorded against the task). As we usually record estimates already factored out to include pair time, this confused us for a while until we realized what was happening.
A few more shortcomings were revealed during the early stages of data entry:
- Every Story Card must have at least one task. Our team doesn't usually track time against tasks, so we've found ourselves having to create a default "Implementation" task for these stories just to give ourselves something to attach time to.
- If your actual hours exceed the estimate for a task, XPlanner will force you to re-estimate the task. This is somewhat annoying, but the original estimate is not lost and appears again in the reports mentioned below.
- Even though you can enter time with mutltiple decimal places (e.g., 2.25 hours), this value is recorded with only one decimal place (i.e., 2.2 hours). So time tracking is not possible to any accuracy greater than the half hour.
Note: with the exception of one developer, the team never uses units more granular than a half hour anyway
- XPlanner cards only recognize broad categories of priorities (i.e., 1, 2, 3 and 4) and provides no ability to maintain a complete ranking of cards. This has forced us to use the BVC to maintain our overall prioritization/ranking for the iteration.
- The process for the most frequent use case (i.e., entering hours against a task) is not particularly speedy. Assuming you've just logged into XPlanner, you require 4 mouse clicks to reach the point where you can enter hours against a particular task.
- It's not possible to record time against a stort/task without an estimate. This is not normally a problem except we have a general "bucket" for Non-Project Work which we have no mechanism for estimating, so we've ended up giving it a large estimate to remove the need to ''grow'' the estimate each time it is exceeded. I fear this might be playing havoc with the velocity being calculated by XPlanner for the iteration.
As you might expect, XPlanner maintains quite a nice set of Web-based charts and tables showing various views of the progress through the iteration. Individual developer timesheets are maintained - nice for removing the guesswork if you have to double enter your time against a corporate timesheeting system (or two :-)). Paired versus non-paired time can be tracked, as well as estimates versus actuals. Project versus iteration velocity is tracked, although I'm not really sure how this is done at the moment. I think we'll have a better idea of how useful these metrics are in the Iteration Close meeting.
I've noticed two positives that have arisen from our usage of XPlanner to date:
- Developers are entering their hours several times each day instead of the morning after. Although this is undoubtedly costing more time, the actuals are more likely to be accurate.
- Being forced to break cards into tasks has generally resulted in considerably smaller overall estimates than those given during the Iteration Kickoff Meeting. So far, these estimates have proven more accurate as well. This is a good thing.
I'll post again with the final analysis of our evaluation, but at this point I don't think we're saving enough time to warrant living with the shortcomings of XPlanner. If you have no mechanism for tracking in place at the moment, XPlanner might be useful, but the flexibility Excel currently gives us is exceeding the extra features offered by XPlanner to date.
Posted by Andy Marks at March 20, 2004 07:05 AM
XPlanner's sweetspot is communication, especially distributed communication (with offsite stakeholders, distributed teams, etc.). One of the issues we had with Excel was that it's not easy for the team to update the spreadsheets concurrently, progress updates tend to happen less frequently, and often one person gets stuck with doing the actual spreadsheet updates. However, I agree that Excel provides some powerful and flexible capabilities for a manager who wants to manipulate the data in various ways.
Some of the shortcomings you mentioned have been addressed in the 0.6.1 XPlanner release. The priority editing has been opened up to allow any set of numbers to be used. This can be used to completely order a set of stories but in the future we'd like to add the ability to interactively order the rows in the story tables.
The number of clicks for time editing has been reduced. For the scenario you mentioned, you'd click on our "Me" link and then click the time entry icon on the task you want to record time against.
Your comment about non-project tasks is interesting. I assume these are not customer stories. I'm interested in learning more about how teams manage and track these types of overhead tasks and the relationship between overhead activities and velocity measurements.
To provide additional precision for time entry, you can edit the decimal format in the language resource bundle. By default, it formats and parses one decimal place (this was there before 0.6.1).
The requirement to re-estimate a task when the actuals exceed the estimate is a requirement for tracking estimated time to completion. If the actual is greater than the estimate, the ETC is undefined. However, I understand the issue with overhead activity tracking. Maybe we could categorize those activities as overhead and ignore them for ETC calculations (?).
I'm looking into ways to support tailoring of XPlanner. For example, to support stories without tasks, unestimated/untracked tasks, point-based estimates, different effort units for stories and tasks, and so on.
Posted by: Steve Bate at May 15, 2004 11:16 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)