Workflow for Enforcement -vs- Detailed Project Planning

Added by Brian Alexander over 8 years ago

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.


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.

Replies (2)

RE: Workflow for Enforcement -vs- Detailed Project Planning - Added by Bruno Samora over 8 years ago

I face exactly the same problem and I don't the best way to avoid it. We've decided not using the Gannt or Calendar views for while and break the issue is something we don't want to do.

Maybe some sort of milestone inside the version would help, but I'm not sure about this.

RE: Workflow for Enforcement -vs- Detailed Project Planning - Added by Brian Alexander over 8 years ago

Right now I am leaning towards breaking the workflows up and using custom fields to link them... For example a development workflow with 'tested-in' custom field for the issue tracking the testing. Then having a testing workflow with 'developed-in' custom field for the issue that tracks the development. This should get the Redmine calendar and gannt chat back to matching what really happens...

I didn't like this idea much when I started but it is growing on me. It keeps the notes for each issue relevant to the current team - testers don't have to wade through developer notes and vice-versa. This also allows me to target the training materials to each team. Analysts and testers are not terribly concerned with code reviews and developers are usually not terribly interested in impact analysis or test plan development.