Redmine

I migrated the company I work for to Redmine about a year ago and we love it. We have configured a set of work flows that help keep us honest about making certain things like code-reviews and formal testing are done, and are done by the right people. However, having each tracker have a propose-analyze-design-implement-review-test helps keep us honest and keeps all of the information relating to the work on that issue in one place. However this style of workflow has one big drawback - it often renders the calendar and gannt chart somewhat meaningless.

Here is the problem: each issue has one start and stop date but the work really starts and stops between workflow steps. For example: testers don't always test each issue as it is finished, they often wait for batches of issues to be completed and test them together. It would be nice to be able to see these start and stops on the calendar or in the gantt so it is clear when the project management really expects the work to be done.

Example¶

Let us say there are two issues, A and B, which will take two days each to implement and one day to test. For simplicity's sake let us say there is one tester and one developer. The developer will work on Issue A Monday and Tuesday and Issue B on Wednesday and Thursday. However, formal testing for the application tends to be multiple issues at one time. So the testers will not test Issue A until Issue B is also ready to test. So testing for both issues will start on Friday.

If the tracker's workflow captures both the development and testing activity then the calendar starts looking a little weird. Issue A will have a start date of Monday (when Development starts) and end date of Friday (when it is tested). So it shows up on the calendar for five days even though work is only being done on three of them. The problem is even worse if you increase the number of issues.

What are you doing?¶

The obvious solution is to break the issue up into two issues/workflows: one for development and one for testing. However, we then loose the benefit of having the development workflow hold teams accountable for making certain things are tested...

I suppose we could make a custom required field for development that was the issue number for testing...

I would really like to hear how you are balancing flexibility in planning with issue workflows in your organization. Even if what you are doing is not working well for you - please let me (and the rest of us) know.