Currently

This is the current life cycle of a ticket on the Jira board.

In Progress

When the developer is looking for something to do they open the Jira board and look at the To Do column. Because the sprint planners did their job properly they can simply take the ticket at the top of the column and know that the priorities are right.
So they pull the ticket from To Do into In Progress.

They start working on the ticket and after an hour or 2 the ticket is done (jeej for proper ticket splitting). They create a pull request for the branch and push the ticket is to In Review.
At this point the initial development is done and they start looking for additional work so they look again at the top of the To Do column and restart the process.

In Review

Every so often they get an email from bitbucket saying they are assigned as a reviewer for a PR. So now and then they go through the dozens of (probably prefiltered) emails to see if they need to review something. They give their remarks and move on to the next PR. When they are through the mails they go back to picking up a new ticket from the top of the To Do column.

If one of their own branches was reviewed this way they will again get a mail and will resolve the comments when they are taking a break from coding. Once all comments have been resolved they merge the branch into master and push the ticket to Ready For Build which ends up in the In Test Column

Awaiting Build

Jenkins is now building and testing the new master and notifies bitbucket when it is successful. The ticket then gets automatically pushed to Resolved which is another subcolumn in In Test and the color of the ticket changes to denote it needs to be validated by QA.

Testing

One of the QA engineers takes up a ticket that is marked by a color. They do the validation and if everything is correct they move the ticket to Done.

The tickets has now done its complete journey from To Do to Done.

What is the problem?

There are a couple of problems with this approach. The first problem is that the focus is not always on the correct tickets. As previously described in Limit your WIP we want to get tickets to Done as soon as possible, usually before starting a new ticket. Currently the reviewing of tickets is not prioritized over starting new tickets resulting in a lot of context switching. Developers are juggling around multiple tickets which is not helping productivity.
But the main problem with this approach is that people are pushing work onto each other. Developers who are finished with their work push it to the reviewers and start something new. There is no guarantee that the ticket will actually be reviewed. Reviewers push the work to testing when they are done and it can take some time before it is picked up by testing. This is a problem because it results in a board that doesn’t represent the actual state of the project.

Proposition

As a first rule of thumb prioritization of tickets will happen from right to left and top to bottom. If there is a ticket in Review it should get picked up before starting a new ticket. If there is a ticket in Testing that has issues found by QA it gets priority over any review work still on the board.

Secondly finishing work shouldn’t trigger a ticket to move, starting work should. It doesn’t really make sense to push ticket anyway. We wouldn’t push ticket from To Do into In Progress when there are no developers available to pick up the ticket. The same hold true for other columns. Pushing a ticket into Testing doesn’t get it tested any faster if there are no tester available. If we have no one reviewing just pushing a ticket to Review doesn’t help.
So a second rule of thumb would be to only allow tickets to be pulled in to a column, never pushed.

As you can see many problems from Limit your WIP are repeated here. Both changes in workflow help alleviate some of these problems and they work well in tandem. These strategies complement each other and implementing both will make the workflow a lot smoother.

Here’s how it works.

In Progress

As before we start by pulling a ticket from To Do into In Progress. When finished with the work we mark the ticket as Ready For Review but we leave the ticket in the In Progress column. Then instead of just picking up a new ticket from the To Do column we look over the board from right to left as per rule 1. Check if there is something stuck in testing, check if there is review work to be done, or review remarks to handle. When there is nothing else to do on the board pick up a new ticket from the To Do column and restart the process.

In Review

Start by dragging a ticket that was marked as Ready For Review from In Progress to Review and give your remarks. When you have remarks either poke the developer so they can fix it asap or mark the ticket as Request Changes. When all remarks have been resolved you mark the ticket as Ready For Testing but leave the ticket in In Review. As per rule 1 you look over the board and if nothing requires attention you restart the process from To Do.

Testing

QA picks up tickets marked as Ready For Testing and pull the ticket into Testing. If they find issues they mark the ticket as such. This means that when a dev is looking over the board this ticket will get the highest priority (as per rule 1, it is the most to the right) and should be fixed asap. If no issues are found they move the ticket to Done and repeat the process.

Following this process ensures that tickets flow through the board as quickly as possible without the need to juggle many tickets at once.