Redmine issue lifecycle for a small development team. Our experience and useful tips.

Redmine issue lifecycle for a small development team. Our experience and useful tips.

I think this article should help people who first decided to automate the process of tracking Redmine issues in a software development group. In this article I'll talk about how we arranged this process with the help of plugin "Luxury Buttons", what new issue fields we have made and what problems are solved by these fields. I think the article will be useful to a wide range of people, in my opinion, lifecycle management is a work under the slogan "obvious - not obvious".

Moreover! We work in a large corporate environment, mainly for internal customers (there are several) and this situation is reflected in our lifecycle.

Let`s begin.

It all starts with the fact that at one moment an issue appears and after its appearance, issue should logically fall to its author. Why? Because issue should always have a person who is responsible for its further execution, who currently inhibits task, somebody on whose side is the "ball", and he should "transfer this ball to another", does something like a football pass. Sometimes this person should not be there. For example, when there is no need to perform an issue, when it is closed.

What necessary information do we ask user to fill when creating an issue?

 

Well, obviously, its: issue type, title and description, but also:

• «Customer» - employee who is interested in this issue and requested its execution. He will also subsequently check the result of the work, and evaluate execution.
• «Purpose» - the ultimate goal, that should be solved by issue. We do not immediately reached this field. On the one hand, why purpose is needed if there is a detailed description, which says what to do? But if you think about it, the purpose is quite another. Issue description tells what you should do to achieve the purpose and if the purpose is not fixed, then, in the process of issue execution, the goal may be lost, and the obtained result may be not exactly as it should be.

For example, the purpose may be:
"Implement the possibility to calculate base part of salary on the basis of an arbitrary mathematical formula."

And in the description there will be more detailed key steps and requirements to achieve the purpose. For example: "MathML library connection, the possibility of linking formula with calculation period", etc.

In the general case, the description depends on the skills of executor and in some cases it may be just a couple of lines (if you have good communication with the executor, you worked well together and understand each other).

Where the new issue can go?

 

Most often it is sent to plan, as we often have priority tasks (well here such a customer focus and customer reluctance to think about the future).

But it so happens that issue is not priority, and then it can go into the queue (or Backlog, as you wish).

If the issue is sent to plan, then we will necessarily ask to fill in the following fields:

• «Estimation time» - how much pure time of the programmer this issue takes, according to the head of development. Almost never this value can be accurately determined. But we need to determine approximately. Because this time, in fact - is the issue price, i.e. it’s not time its money, per which the customer buys execution of this issue from development team.
• Start date and execution date. Here everything seems logical. Also, when a programmer unnecessarily squander issue by terms, then it affect on his salary.
• «Stage» - plan, version or sprint, in which you plan to perform the issue. Our stages match with months. By stages and executors we monitor the progress of work.
• «On whom» - the employee responsible for the execution of the issue.

At the moment of setting issue in plan, value from issue field «On whom» is always copied in field «Executor». Issue will sooner or later leave from the employee responsible for its execution, but the responsibility for the execution should not get away, so each executed issue should always store its executor.

If issue goes into queue than there are fewer fields to fill:

• «Priority» - helps to draw higher-priority issues from queue first.
• «Estimation time» - helps to decide, what will fit into future plan and what will not.

And of course, issue from the queue can always get into the plan, and may be closed and get the status «Closed». Status «Closed» is fundamentally different from status «Executed» as there has been no work performed on issue.

What executor can do with issue?

Two controversial, but having the right to life functions «start» and «pause», which respectively change task status from «Assigned» to «In Progress» and vice versa. In small groups, this feature is not really caught on, and in some large groups it does. If there are a lot of programmers and they mark issues which they execute in the current moment, it is possible to build a section of issues which are currently in the work at executors (some kind of «Work in Progress»).

Almost in any status of issue, employee, whom the issue is currently on, may request information from the author, head, customer, etc. Of course, the executor is no exception.

Of course the main function for the executor is the ability to send issues to check and the same button «To check». Button sends issue to tester. Programmer must fill fields:

• The field «How to check» - amazingly simple and useful thing. For the first time, I read about this field in some book about «Scrum». Programmer, handing issue to check, should write tester and the end customer, what you need to do to take advantage of new opportunities: what branch of the repository to take, what settings to make, where to go in the interface and where to click. As a result, miss of many unnecessary questions from the tester, the customer and the team leader.
• The field «What has been done». The programmer does not always do what was originally written in the description of the task. Sometimes doing something extra, sometimes the programmer is given free rein in execution. Through this field programmer inform the head, the customer and the tester exactly about what he did in result of executing. Among other things, we have implemented a monetary motivation based on customer issue evaluation and programmer in this field can pay extra attention of customer on features of task execution, which may lead to an increased evaluation.
• The field «On whom» - the tester, who will check issue.
• Checkbox «I pull the issue result on the test server». Without filling in this field, issue can`t be sent to check. A tester has its own test server for checking issues, but before you transfer issue to check, programmer must pull it in working condition on the test server. First of all for head to be able to appreciate the quality of issue execution and he did not have to ask once again to pull issue on a test server or do it yourself.

After sending issue to check its status logically changed to «On check». Now tester is responsible for further issue execution.

What tester can do with issue?

Well, of course: send issue back for revision (button «Return back») or skip further to production-server (button «Checked»).

He may also change the checker (and the same button), and in our group it is administratively establishes that issue should pass through the head for the second check.

Why head`s check is need:

• Firstly, it is the second check and the second check is rarely superfluous.
• Secondly, I am tormented by perfectionism concerning design and usability. And I am terrified when I see that the interface could be done cuter but issue is already slipped on production server.
• Thirdly, pulling issue on a production server may require notice of a certain group of stakeholders and decision on the necessity of notification may take only the head.

In any case, the transition of issue from the status «To check» to the next status «In use» is accompanied by filling a handful of fields:

• «Check mark» and «Description to check mark». Tester or head can put this mark. This mark also allows to affect the programmer`s salary.
• «Desired date of use». When it would be great to pull issue on the production-server (in our group individual employee is responsible for pulling).
• «Requires notification». Does it need to inform employees about the availability of new features or something else? If required, tester must do it before pulling.
• «Presentation». When the task will be presented to the customers (this is an interesting procedure, but I will tell about it in another article).

Also there are a lot of checkboxes for checking issue before sending it to the production environment. Shall list them, suddenly it will be useful for someone:

• I checked the absence of cyclic and recursive queries through SQL-RackMiniProfiler.
• I checked the layout on different resolutions of browser.
• I checked the layout and working capacity in latest version of different browsers (Chrome, Firefox, Opera, and Internet Explorer).
• I checked the working capacity of the plugin on different databases (MS SQL server, Maria DB, PostgreSQL).
• I checked the execution of issue for compliance with the fundamental rules «Basic rules of writing plugins for «Redmine»».
• I analyzed the necessity of notification of employees. Noted the need of notification in issue.
• I analyzed the necessity of updating information in instructions (if necessary opened an issue).
• The task is pulled on a test server.
• Opened issues for writing autotests.

 That's such not easy test procedure.

 What Redmine administrator can do with issue?

 

He can pull it to a production server, thereby transferring issue from the status «Checked» to status «In use». Task is assigned to the customer.

 What customer can do with issue?

 

 Customer may accept or reject the work. If rejected, he sends issue to tester for re-check, writing a comment. If accepted, he presses the button «Done» and puts down mark of execution and an explanation of the mark. These marks affects on salaries of executor and head.

 

Taken together it turns out such an issue lifecycle scheme.

There are much larger transitions between the statuses than it is described in the article. Most of them are privileged transitions for the head when he need administratively transfer issue to the next state without waiting for the programmer or tester.

Of course it's not all that we have in the issues lifecycle, but if I wrote about all that probably would have been a little book.

I would be glad if you share information about what lifecycle you used? Which fields you ask employees to fill when track issue and why?

Thanks to all who read to the end.