Next up on my look at RTC is Project Planning.
This will include how RTC supports the process of planning iterations and releases, task boards, estimation and tracking, backlog management.
Again I will use Jira + GreenHopper as a reference since that is what I use at home, there is other similar tools out there, one example is Mingle from Thoughtworks.
Again this is both subjective (my opinions) and based solely on my experiences from home and work, and I might criticize either for things that is merely a setting you could switch on and of. Un-fortunately It won’t be compared based on the exact same processes, I don’t feel quite the same need for tracking on a spare time project as we do where I work, properly because I don’t believe so much in tracking and estimation using hours and minutes, and I would rather track based on “items”, one of the huge advantages of working without a budget.
Planning Iterations and Releases
Both solutions has a good support for planning iterations and releases, at least to my interpretation.
In JIRA the concept is extremely simple, on the very basic level all you have to work with is “Versions”, in JIRA alone Versions is just a name and a release date, the same concept exists in RTC and is called Releases.
On top of the JIRA versions, GreenHopper adds structure where Versions can be organized in a tree structure, but they are still individually a very simple version, in RTC we add the concept of Timelines and Iterations or Plans which i think is a umbrella term for those and maybe more.
But that is the “data concept” under it all, the more interesting thing is how we can use it, and here things begin to go wrong for RTC.
First of all, what seems to be the “planning tool” is really poor compared to GreenHoppers planning board, and items not assigned to a “plan” seems to get lost which is really bad, one of the reasons here is that your view of this board seems to be bound to a Plan, so the “RTC Planning Board” can only be viewed from the perspective of a Iteration.
Below is a screenshot of the view.
Don’t mind the “Estimate, effective estimate” and so on, those are a bit fucked up for us atm. I guess what is really wrong here is that they try to do to much in one view instead of making things more simple. I won’t go into the details, but you can drag and drop items from E.g. the “Release 0.1” iteration and down to one of the sprints as the screenshot shows, you can also select multiple items and do that.
Sprints can be “folded up” and you have some indicators of weather or not a sprint is full, or at least i think. And some progress indicators and so on. And I do think it is also sorted by rank (priority).
GreenHopper takes a different approach, the planning board gives you an overview of all the unreleased planned versions and then all unscheduled issues as displayed as if it was a “unscheduled version”, this makes it really cool and easy to use. Below a screenshot where I also are about do drag an item from unscheduled issues to the planned version 0.1.0.0
The first thing one can see is that it view is much more simple, one could argue that RTC holds the advantage that you can see the items in both the one you drag from and the one you drag to, well fair enough it can in a rare case maybe be an advantage, but if you have prioritized your “backlog” properly, then all you should need to do is drag items from the top until the iteration is released and that should be it.
It also means you don’t need the “parent-child” relation at all, and I actually prefer not to use it although I have added one in the screenshot above just to show how that is displayed.
The only conceptual downside I could think of with GreenHopper is that you can’t have iterations that isn’t also a release, so they all needs to be “released”, but I actually prefer it like that since it forces a version mark for each completed iteration which only makes sense to me, no one is saying that the “release” part means you skip it to the customer.
Task board
The task board is what you use for daily planning, for some that is the scrum meeting, for others something else.
I personally prefer an analog approach to this because it often becomes a million times simpler and does not give issues, but if your working in a distributed team then the analog version won’t work so we have adopted the RTC task board for that. And at home I actually use the GreenHopper task board for item transmissions because it is so easy to use, so even though I prefer the analog version, I have used both systems allot when it comes to this subject.
And ones more RTC disappoints. At first glance it actually seemed to have a really good task board, granted that it is a little more rough in the design (like it was quickly hacked together), and besides the smaller details there is a few major ones which are:
- Task Transitions is broken.
- Spent time is not logged but rather set, and it can’t be set higher than the estimate (or we get a save conflict).
Both things that work excellent in GreenHopper, but lets first take a look at the boards first.
First screenshot is from RTC, and I am in progress of dragging an item.
The board it self looks ok, the story column is completely unnecessary, but can properly be removed by configuration, the default configuration clearly has it though, and that's not the worst thing, stories is actually placed in that column and can’t be dragged, so It is effectively a column with no real use what so ever. Every item on this board should be an item you can do progress on and close, and in that sense move from left to right.
Drag and drop is completely free, and you can drop an item anywhere you want, be aware however if you drop an item onto another we have experienced it becomes a “sub item” to that one, why anyone would want that to happen on this board eludes me.
A funny detail is that items are arranged a bit random on the board in other browsers (e.g. Chrome) but I did not take a screenshot from that browser as RTC shows it as unsupported, and I think it is silly anyways, like they are trying to mimic the “chaos” that we can have on a analog scrum board.
GreenHopper looks very much like it as the next screenshot shows.
there isn’t that annoying column, and drag and drop is somewhat more locked (Items are only dragged in a straight line across), a clear indication of where you are about to drop the item is added.
Column Capacity
I actually randomly discovered this in GreenHopper, it actually also might be possible in RTC, but at least I couldn’t figure it out.
But as this screenshot shows, one can have entire columns colored under certain circumstances.
Now why would you want that?
Well the top one (Red) is when a column exceeds a capacity, and on our project that would fit very much into our “closing mentality”, the idea is that we are a number of people on the project, and each person can at max do one task and has to close that before he/she opens the next one and so on, obviously that is very strict.
However our “rule” allowed for a bit of “overhead”, so as an example 6 members mean that we was allowed to have 6 tasks open at once, and because we use pair programming that actually allows for 3 more tasks than needed.
That means that if we at any time had say 7 tasks open, that was in indication of to much “context switching” which generated overhead as well as not focusing on completing tasks, so adding this rule/mentality to the project really helped with the flow.
So back to the board, this feature can help us here since we would have been able to configure the “max capacity” as 6 tasks, and we would have a board that told us when we was in the before mentioned situation.
The bottom one (Yellow) is an indicator for when you go below the minimum capacity, I guess this could be useful in a more “kanban” style board where if the first column suddenly didn’t have many tasks left that was ready to start on, then it would warn about that.
Personally I don’t use any of those at home.
Transitions
So what was this about transitions being broken in RTC?
For both solutions each column in the task board displays items in one or more specific states, so one column can actually contain more than one states.
- So wait, how does the system know what state to put an item into when we move it?
In GreenHopper there is a few ways, the implicit one would be a workflow transition, so the “To Do” column holds 2 states, Open and Reopened but when dragging an item from Closed or Resolved it can only transition into Reopened, so that is the simple implicit one.
But for Open, Reopened and In Progress items going to the 3rd column which holds both Closed and Resolved issues, a Open, Reopened or In Progress item is allowed to transition to both those states, so what do we do?
A “Small” dialog asking what transition you would like, now this may seem a bit annoying if you would use it for your daily scrum or something like that, but when it comes to RTC, well for now stories transition into “deferred” as default, which means you then have to go in and correct their state after.
A Better solution would maybe be to have “drag to areas” that denoted the state you wanted to transition into, but at least GreenHopper has a solution, where it seems RTC falls short, again this can be a configuration bug, if RTC has anyway of doing the same little trick by all means let me know so I can kick the ones managing it!
That said, I don’t use the 2 states in JIRA, so my GreenHopper does only have one state to display in the 3rd column and so the above dialog does not appear in my configuration.
Time Tracking
The next one was time tracking, RTC has a little field below the estimate on its items, we haven’t gotten it to work yet but it seems you have to add up the hours your self as you go along, and it acts as a combo-box where you have a set of predefined values, and finally you can apparently not “use” more time than what you estimated.
So the question is, what is the RTC model even useful for? But might again be one of those things where the Default template from IBM is just inadequate, or maybe our RTC management team that has configured it poorly.
Here you can see the simple one for RTC on the left, and the whole log work thing for JIRA/GreenHopper on the right.
What happens in JIRA/GreenHopper is far more intrusive, but in the same time that much more useful.
What you get is a menu or a “field button” on your issue, and when you click that you get the dialog shown where you enter in the time you spent and what's left where you have the option to let JIRA/GreenHopper adjust it automatically for you.
The hours is “accumulated” and so everyday you just log the previous days work and it will add it up for you and ultimately show if the issue has gone over time or not. (the little red flag indicates that I am over estimate on this issue)
Estimation and Tracking
Last subject for today, this is not about the Time tracking thing, but rather all the indicators we can get from the different systems.
Below is a series of common graphs you may want to keep tack of, all of them are taken from the “Gadgets” instead of the full size ones… (because I don’t know where to find those in RTC)
The first set is a graph indicating how many Issues/Tasks has been opened vs how many that has been Closed/Resolved over a period of time, the left/top one is from JIRA and the right/bottom one form RTC.
Evidently the JIRA one is much somewhat more useful, at least I think that is obvious. The RTC one simply does not scale with the gadget size, which makes it really small. Also the color area in the JIRA graph gives one a clear indication of weather we are resolving more issues than is created or the other way around, you can see that for most parts I have added more issues than I have resolved.
The graph from JIRA is cumulative while the RTC is not, but they are not exactly the same, just the closest fit I could seem to find. This means that the JIRA one tells us something about the flow in Issues where the RTC just tells us a “number” for that day. I don’t think there is an exact match in RTC to the JIRA one, and when working with Defects the JIRA one can be most valuable, I use it for everything and still find it usefull.

The next ones are a classic, the Burndowns, a simple graph that shows you how your iteration progresses, since I don’t use hourly estimates at home I used an Issue Burndown from JIRA vs. an Hourly from RTC, again the RTC one does not fill the area like the JIRA one does.
Another thing to notice is that they contain different indicators, they both have the “remaining” which is the blue bit dots in RTC and the green line in JIRA, you can se that I tend to add more during an iteration, again an effect of my work style at home, on the RTC one you can se that we are a little bit behind the Ideal line, this line is shown in Red (JIRA) and Brown (RTC).
The blue line in JIRA is hoe many Issues that was created on a specific day, you can se that it adds up quite well to where my “remaining” goes up. RTC has another line which is gray and shows when items are added or pulled from the iteration, you can se we have added a bit about 25% into the sprint.
The green line in RTC is at best comparable to the Brown one in JIRA, well the Brown line in JIRA shows how many Issues I need to close daily to complete, in my situation that is constant at one, that is because there is more days left than there is issues, and one is the minimum it will display. The Green line in RTC shows somewhat the same thing when we look at its angle, but we don’t get a clear indication and it really just draws a line from the number of open hours to the planned complete, so it could be left out and we could still se the same thing.
JIRA has one last little detail, the “remaining” line continues as a dotted line, this is a prediction on how the iteration will end with the current flow, as you can see it predicts that I will have more issues than when I started, this is really just a straight line from the starting point and then through the current remaining work.
Conclusion
Again, I don’t mean to be harsh at RTC, but there is still a long way for IBM with RTC before they even get remotely close to at least JIRA, and I suspect other solutions out there as well.
And this is just the tip of the ice, and I did not even want to get into the “configuration” interface which from the short time I looked into it looked really horrible from RTC where it is a bit more inviting in JIRA/GreenHopper.
I can’t say that RTC isn’t more flexible, or adds allot of neat stuff, I just haven’t seen anything yet in this part of RTC that is not either as good or better in JIRA/GreenHopper.