1

At the moment in Jira each developer has the following columns in its dashboard:

(developer dashboard)

TO DO       IN PROGRESS     IMPEDED     QA  REVIEW      DONE

Story 101 -----------------------------------------------------------------------------
           Development

Story 102 -----------------------------------------------------------------------------
                                              Development

Each developer can create a certain number of tasks for each story. One task for each story is created for testing and assigned to the tester from the beginning.

The tester has the following dashboard:

(tester dashboard)
TO DO       IN PROGRESS     IMPEDED     QA  REVIEW      DONE

Story 101 -----------------------------------------------------------------------------

 Test

When the story is ready for testing the developer move the testing task to the QA column (although he cannot see it from its dashboard).

(tester dashboard)
TO DO       IN PROGRESS     IMPEDED     QA  REVIEW      DONE

Story 101 -----------------------------------------------------------------------------

                                       Test

The developer has to rely on notifications sent via email, when a test fail and the testing task is assigned back to "in progress" (the testing task is never assigned to the developer):

(tester dashboard)
TO DO       IN PROGRESS     IMPEDED     QA  REVIEW      DONE

Story 101 -----------------------------------------------------------------------------

              Test

In addition to this, for reviews the process is not very linear, as the task is not assigned to the reviewer but just moved to the column REVIEW:

(developer dashboard)
TO DO       IN PROGRESS     IMPEDED     QA  REVIEW      DONE

Story 101 -----------------------------------------------------------------------------

                                           Development

There might be multiple reviewers and the only way to know you have to review a story is to login to Bitbucket and see if there are any pull requests. When somebody leaves comments, you have to constantly check the pull request to deal with the comments.

Another problem here is that the tester not always waits for the review to be completed (approved by everybody in the pull request). In fact the "development" task can be in "review" state and at the same time the "testing" task can be in the QA state. The tester sometimes start testing before the end of the review because there are no other stories to be tested, but the consequence is that he has to test again if there are any changes to the code.

As you can see the process is quite convoluted and not linear. How can I improve the process? what are we doing wrong?

closed as too broad by Venture2099, Sarov, Mark Phillips Feb 26 '17 at 20:15

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • There is way too much going on here to provide a meaningful answer. – Venture2099 Feb 16 '17 at 15:44
3

To me it seems you have a lot of process that actually hinders your progress.

Why don't you just create a single dashboard for all and if somebody needs to do something you assign the original ticket to them.

For example: When the developer is done he moves the ticket to the QA column. He then assigns a QA or assigns it to a QA pool where they pull from.

  • we cannot work on a single dashboard because there are too many developers and it would look messy. Also we cannot assign the ticket for review as the reviewer are usually more than one – user1883212 Feb 16 '17 at 15:10
  • @user1883212 Then have one dashboard per team. If you cannot assign a reviewer, how do you know who reviews? – nvoigt Feb 16 '17 at 15:12
  • Add the moment each developer constantly check the pull requests to see if they have been added as a reviewer in one of the pull requests. They also receive an email when this happen. But there is no visibility in Jira. Regarding the teams, we only have one team. – user1883212 Feb 16 '17 at 15:26
  • If you only have one team, why would one board be messy? And how does a reviewer added to a pull request, when the developer does not know the person needs to review? – nvoigt Feb 16 '17 at 15:28
  • Messy just for the volume of tickets, because instead of looking at the 3 or 4 tickets assigned to you during the sprint, you have to look at 30. Regarding the pull requests, the developer add any colleagues he wants for review (usually 2 or 3), but the reviewers are not notified in jira (just by email). So my point was: why can't we manage everything in one place (with a proper dashboard) instead of 3 places: dashboard, email and pull requests page. Also many things do not make sense to me, as the "testing task" can only move in a couple of columns and sounds illogical to me. – user1883212 Feb 16 '17 at 15:33
0

I recommend simplifying your process and using only 3 columns: To Do, In Progress and Done.

When it comes to subtasks, you can extend your existing subtask list and include the following:

  • Develop (or implement)
  • Review
  • Test

Each of these will be assigned to a single person at a time and you can always synchronize verbally in the daily standups. e.g. When the developer is done with the "develop" subtask, he will move it to done. He will then assign the "review" task to the person who volunteered earlier. When that's done, the QA person can pick up "test" subtask and proceed with it. In case there is a bug, the "test" subtask will remain in progress, a separate subtask will be created for the issue and assigned to the developer. When the developer is done with the fix, he assigns the subtask for the issue to the QA person again for verification.

Any point in time, the status of the story will be visible.

Not the answer you're looking for? Browse other questions tagged or ask your own question.