Redmine

We have been using Redmine heavily for almost 6 years (replacing our previous project management tool which was developed in house). We are now running 3 instances of redmine for different client/project groups totalling about 17,000 issues. I am posting a detailed explanation of HOW we use Redmine because:

1. It might be useful for others just starting out.
2. It may prompt others to share their secrets and to build a library of best practices.
3. I invite comment and criticism - there may be better ways of achieving my goals
4. We are still on version 2.0.3 - there may be newer features we could take advantage of I have missed.

• Table of contents
• Methodology and Measurement
• Workflow
• Ownership
• Sprint
• Priority
• Patches
• Groups of Tasks
• Summary

Methodology and Measurement¶

We used to try and be a Scrum house but found it ill suited to the tempo of our work (we have major systems in production and development emergencies arise every week making the protection of a monthly backlog impossible). We have retained some aspects while moving our focus more towards Kanban and trying to minimise work in progress.

We maintain an "Active Queue" which when refilled with the next batch of tasks to happen, will contain 7-10 days of work. Developers pick their own tasks from that queue and are rewarded (monthly bonus) based on total points completed. Each task has a points score assigned by me and me only - we do not have estimation meetings. My estimates are often wrong (and I sometimes increase for tasks that turn out much harder than anticipated, or where scope creep arises) but because developers pick their own tasks, my inaccuracy is fairly distributed across the teams and developers.

Every day my secretary distributes graphs and spreadsheets showing (on a developer, team and project basis) how many points were completed this week to date, last 4 weeks average, last 12 weeks average. Developer bonus is based on average for the 4 or 5 weeks in the salary month, while quarterly prizes and biannual performance reviews are based off longer averages.

I am stressing the quantitive measurement aspect of how we use redmine because it is the most controversial and unusual practice we follow. Conventional Wisdom(™) dictates that you can't quantify developer productivity - and even if you could it would be counter productive. I have been developing software for 30 years and have often found conventional wisdom to be an unreliable guide. You can attempt to quantify in a way that is useful (at least to me) in terms of delivered units of functionality etc - whether it is counter productive to do so is a matter of opinion.

A nice side effect of tracking velocity in this way is its use in predicting how long new blocks of functionality will take to complete (the conventional use) but I can also see that while numbers vary widely week to week, over a 12 or 25 week period some developers are not just slightly more productive but 200%-400% more productive. I like to track such people and reward them appropriately.

Workflow¶

Our list of task status values consists of:

1. New - not in play yet.
2. Pending - generally in the active queue and part of "Work in Progress"
3. Design/Clarify - a catch all status for issues that need more information from the author or project owner.
4. Develop/Rework - assigned to the task owner to be created/improved
5. Branch Test - assigned to team tester to check
6. Approve for Upload - Go/No Go from me
7. Upload - team leader will merge in Version Control, check, and push to production
8. Live Test - assigned to team tester to check
9. Final Acceptance - Back to me for review
10. Closed

This is all quite conventional I think. Different people need only watch for tasks at selected status values:

1. Developer: Develop/Rework
2. Tester: Branch Test, Live Test
3. Team Leader: Upload
4. Me: Design/Clarify, Approve for Upload, Final Acceptance

In this way we attempt to decouple everyone and preserve a free running production line.

Ownership¶

Which brings me to our first custom field: Owner. Conventionally in Redmine you assign a task to a developer and then he assigns it back to the author for clarification who assigns it back, then on to tester etc etc. At the end of the trail when it is closed I need to assign it back to the developer to ensure he gets his bonus - but it can be hard to see who actually did the work on that task in a sea of updates.

Another issue is that a developer can end up with 6 or 8 tasks all assigned to him. He starts multi tasking, picking up first one task then another. They are all urgent - what is he to do?

Lastly there is always one task he/she is procrastinating on - it is the one where there is uncertainty or tedious work to be done. As long as there are alternative tasks to work on that task can linger a very long time, sometimes undetected.

To address these issues we made some subtle changes with profound impact:

1. We added a custom field "Owner" of type User. When a developer 'picks' a task from the queue they assign themselves as 'owner' - they take ownership and responsibility. During its lifetime the task will be assigned to half a dozen people on its road to completion but at every step he/she remains the tasks owner.
2. We banned developers from taking tasks when they already have an active task - in many cases they previously used to grab easy or interesting tasks out of the pool to avoid losing them, even when they had a task in progress. To enforce that developers had their workflow amended to block the transition from Pending - only my secretary, Ops Manager and Myself can assign new tasks. This has eliminated that problems. [Aside - yes this is an inevitable consequence of tying bonus to task point completion.]
3. Although a developer can still end up with 3 or 4 tasks that they own 'In Progress' they should assign only 1 to themselves. Everyone considers their designated task status values to be their pool of tasks. When they finish working on one task they pick the next and assign it to themselves (so that others can see which one they are working on). We strongly discourage multitasking.

Using these simple tricks we cut the 'in progress' task list for a 5 man team from 60+ to about 10 tasks at any given moment. Being able to see the whole list on one page of redmine brings tremendous clarity and peace of mind for me.

Sprint¶

We changed our sprint length from Monthly (typical for Scrum) to Weekly (better fitting our Agile business) and added a new custom field "Sprint". Sprint has values such as:

1. Unscheduled
2. Active
3. 5th May 14
4. 28th Apr 14
5. 21st Apr 14
6. 14th Apr 14

Tasks start off unscheduled. There is a large pool of tasks there (after 6 years you acknowledge that many will never be attempted - it is normal). Once they go in the active queue they move to Active. There they stay until closed when they field is updated to show the week they were closed in.

This system lets me get the stats for the tasks closed in each weeks sprint. Previously I used to use the Updated field but in cases where historical tasks need to be modified it moves tasks into the wrong sprint.

Note: I have been doing some analysis by SQL and now wish this field was a Date value so I could sort more naturally.

Priority¶

This is a tough subject! First of all there are the conventional priority levels such as

1. Low
2. Normal
3. High
4. Urgent

But I have never found them very effective because:

1. Everyone thinks their stuff is above average in priority - nobody sets tasks at low.
2. Out of Urgent and High which is a higher priority - unless you see them ranked as here it is confusing
3. If you encourage clients to file their problems directly into redmine you end up fighting with them over their perception of priority vs the global picture.

So we made two changes. First we modified the list to:

1. Normal. Most tasks are normal.
2. Urgent. If you must. I take no notice of this.
3. Emergency. Used by me to fast track issues that I need done yesterday. These issues are shaded red by CSS in Redmine.

Mostly I let my clients set tasks as Normal or Urgent as they please and take no notice because I have my own priority - using a custom field (with an unobtrusive name and type integer) I assign these values to new tasks:

1. (none) - not going to happen unless I get nagged by the client
2. 1 - Strategic but not urgent. All the tasks like refactoring, reviewing security, designing bold new features which we should do when we can.
3. 2 - Normal. New Features and Bug Fixes - all our day to day work.
4. 3 - Express lane. Flavour of the month tasks.

I model this on the Express queue at my local Universal Studios. People with Express pass go in a special lane with perhaps 10 people in it while the standard lane has maybe 200 people. But the staff dont fill all the cars from the express lane - they take people about equally from both lanes, the express lane is just faster because it is so short.

So each week when refilling the queue I take a bunch of tasks from the Express Queue, but I take care to always take a couple of tasks from queue 2 and 3 as well. It is critical that all the queues keep moving although in the longer queues it takes longer to reach the front.

Oh and I have the tasks sorted by CREATED DATE ASC - I take the oldest task first. If I no longer like it I am not shy about demoting it to a lower queue and waiting for it to reach the front of the slower queue before reviewing again.

Its not perfect, but it works for me. In fact I now use a similar 3 speed queue for my personal ToDo list as well - because I am always working on my oldest task I always know how long (old) the queue is and whether I am getting overloaded.

Patches¶

As well as our custom fields we also developed a couple of patches for Redmine. The first lets us see the total estimated time for any group of tasks when grouping in Redmine:

Note that while hovering over the label I also get an Expand All/Collapse All shortcut as well - I think we did that too.

Secondly at the foot of each page we sum the total estimated time for the page and the whole set:

Thirdly we made a hook to add calculate % done for groups of tasks based on values of each of the children:

Groups of Tasks¶

I tried to use Redmine's Target Version functionality but it did not fit with our style (continuous integration and deployment) and in early versions of redmine the list quickly got long and messy (later versions suppressed closed versions).

Instead we heavily use the sub-task system. We have a designated tracker "Group" which has no significant difference, but is reserved as a parent for other tasks (including sub groups). When tasks exceed about 8 points I normally attempt to break into smaller units under a parent group.

When there is a group I will put the priority (queue) number on the group and not on individual tasks. Since we follow Kanban and minimise work in progress once a group is started it becomes a high priority to complete all the subtasks.

Summary¶

OK so we are a bit unique and have evolved some rather custom workflows that suit us but would not work well for everyone. However I am sure others have similar tales to tell and I am always interested in hearing how people have evolved to work more efficiently. Please reply with your own best practices.