Using a JIRA Board effictively

A Kanban Board is part of the lean management or in our case the lean software idea. Lean software states seven principles, where a Kanban board is a tool supporting mainly the first two principle:

• visualise your workflow and
• provide regulary feedback.

Jira Software has a Kanban board included, but if you are a developer and not trained with the ideas behind it, you will probably not use it very effectively.

Visualise your workflow does not mean painting nice images of what you are doing. Instead it is targeted to optimize the flow by reducing your cycle time (thr number of days an issue takes from creation to being closed). A Kanban board solves these typical problems:

• How long take my stories in average to be available to my customers? How can I use this data to make a prediction, when something showable is ready?
• Where in my process does not happen anything with my issues? Where do I loose time?
• Identify and resolve process and resource bottlenecks:
  • Which column is slow and therefore where should I start with improvements?
  • Are there issues blocked and cannot be processed?
• Decide and change, which feature should be done first (Ordering issues)
• See items with a high risk or time criticality (Priority)
• Provide an overview of your current flow - the items you process currently.

I try to show, how to tune your Jira Board with this ideas in mind.

Kanban Board found on Wikipedia

An example flow

To make it more realistic, lets assume, we have a flow to develop and maintain a web based software product. A story in this process moves from business exploration over implementing and testing until closing.

On this boards are these roles included:

• Marketing - interface between customer and IT
• (feature) Development - implement the features acceptance criteria. Provides second and third level support.
• Testmanagement - write and execute testcases for a feature
• Deployment - creates releases and move them in production

All roles may talk wildly to each other, but a ticket is always assigned to one team at a time. Parallel work can be triggered by opening new tickets or sub-tasks.

See the process, a story ideally takes below:

#	Phase	Column	Happy Path	Possible exceptions	Accountable stakeholder
1.1	Exploration	Receive an idea	Feedback is sent for a new feature	No feedback channel available, e.g. no ticket system.	Customer
1.2		Business review	Business decides to do this or to decline it	No business case	Marketing
1.3		Business refinement	Business writes acceptance criteria, what is needed and defines possible deadlines and constraints. Business defines success criteria, e.g. in sales increasement.	Feature not understood, constraints not possible to hold (date, expenses, market research)	Marketing
2.1	Development	Tech. review requirements	IT reviews the requirements and rate complexity	Unclear requirements, technical not possible, takes too long	Development
2.2		Coding	Implementing, Documentation, Automating for acceptance and success criteria	Bad requirements, too high complexity	Development
2.3		Testing	Verify acceptance criteria and connected systems.	Test fails	Testmanagement
2.4		Cleanup	Developer try to reduce technical doubts		Development
3.1	Testing	Release		Test fails	Deployment
3.2		Release Testing	Verify acceptance criteria, run regression tests		Testmanagement
4.1	Deployment	Deploy to production	The feature is available in production and activated. All or some customers can use it.		Deployment
4.2		Dedicated Support	Logs are monitored intensivly and alerting are adjusted.		Development
4.3	Closing	Success validation	Validate if success criteria have been met.	Data is invalid.	Marketing
4.4		Done	Feature is life and runs stable		Development

It should be obvious, that a single board with every status from our above workflow is too big. So you need to have several boards: Usually one for each team, since a team is physically located in the same place and a Kanban board is then usefull, if all team members have easy access to it. Beside that a Jira based board is only readable with fife to six columns at most.

Using a physical board

Design a physical board as you like. You have no constraints regarding the column layout. But you might need some kind of alignment meeting with the other teams (Development, Testmanagement, Marketing, Deployment). I have no experience, how this alignment meetings are done in practise, but I could imaging to hand over cards with features to other teams, when responsibility changes.

Using a Jira board

With Jira you do not need to hand over cards by hand. But having specialised team boards is still a good idea. Lean Management calls this flight levels - it is explained here, but basically sais a developer has a different view on a problem than a person working in rquirements or in a management board. By using a single issue over all teams, you are able to track your value stream map and get worthful time data from it.

Alternatively use follow up tickets. When a ticket is closed for your team, create a new one and assign it to the next team. This approach could work but makes reporting over the whole value stream quite hard.

Below is a development team representation of our example workflow.

• No status is hidden by the columns or appears suddently - even if it is in a different team located.
• The board has only six columns and is readable on a normal monitor.
• The issues with a status of non development roles can be hidden by a quick filter to increase visibility - if you do not like to have them in an own swimlane.
• Pulling issues is (mostly) supported.

A Jira board for the role development

In order to support pulling, I would implement these additional board behaviours:

• The assignee sould be removed if an item is moved forward. This supports pulling issues.
• The assign issue screen should appear if you move an item backwards. You might not want to directly assign it in every case, but you probalby want to comment, why it is moved backwards.

Jira systems

What is better - one instance with a lot of users, or several jira instances with less users?

Jira has two main products:

1. Jira Software for developing software products and do issue tracking in projects.
2. Jira Service Desk to let customers report bugs or feature reuquests.

My text is about tracking issue in a project, and therefore I am referencing to Jira Software. Anyway below my personal opinion about the setup of Jira Service Desk:

For Jira Service Desk - and especially if handling external customers - there must be a single point of contact (or more concrete here a single Jira Service Desk instance). Service Desk agents will distribute tickets into other systems. I saw a setup, which had five and more different starting URLs for handling feedback of internal employees. No one had a clue, which project should be used for which type of problem. Remember, if you receive an issue from a customer, you can still link it to a ticket in your personal Jira Software, where your customer has no access to - and your can talk more open about sense or nonsense of the original request. But now back to Jira Software.

I have seen two extremes in my carreer: first a setup with several Jira Software instances existing partly one for a single team. Second a single Jira instance with nearly the same process of all IT employees:

Two possible Setups: decentral instances vs. central instance.

Setup	Category	Characteristics
One central instance	Customization	Central project workflow, individual workflows are hard to establish. Plugins can grant a volume discounts.
	Administration	Central available, no team knowledge required
	Corp. Governance	Easy to set, since there is a central Jira Admin team.
Several team instances	Customization	Special Plugins are more cheap, since they might required less licenses on a separate instance. Supports form follows function. Jira workflows and screens can be customized to the teams’ individual working process.
	Administration	A team must name a responsible jira admiministrator, who handles updates, licensing and customizing.
	Corp. Governance	Harder to establish, only if the team responsibles are supported / trained in the corporate requirements. Monitoring and Auditing might be problematic as well.

The way you use Jira depends on your company structure. In my opinion, if you tend to work agile, then try to get your own Jira Instance. The administrative overhead is quite small and you can get massive improvement from customized workflows, screens and custom fields. Experimenting (try, fail & improve) is very, very cheap. And plugins are cheaper as well, because you do not need that many licenses.

Bottlenecks

Where should you start optimizing your flow?

A bottleneck exists,

• if there are too many items in a column or
• if too many items are waiting for something and therefore are blocked and stay too long in a single column.

A bottleneck in this sense is not, if the average time in coding column is fife days, but in column measurement results is two month. This time depends on the kind of work.

A board with a bottleneck in column II and III

Column II: There are not that many issues in this column, but 4 / 5 are marked by a red dot, which make them be blocked. We have a problem in progress in this column, which needs a deeper investigation.

Column III: 10 issues are in this column, but in the columns after this are only 3 issues. You should check if this is ok and set a WIP Limit to make the column red, in case this is a problem.

How is it visualised physically

If you use a physical board, and you are not able to put new cards in a column, then you have a bottleneck. Mark blocked items with a red pin, which can be removed, when the card is not blocked anymore.

Another way is to set blocked items in an own area of the board. If this area is full, then you have a problem with blocked items:

Blocked issues in an own swimlane

A physical board with an own Swimlane for blocked cards.

How is it visualised in Jira

Jira can define minimum and maximum work in progress limits for each column. You should use them - even if you do not know the exact values right now. If the WIP limits are violated, you will get a yelllow or red indicator on your board.

Imagine you have 4 developers in your team and 2 testers. You know a tester can automate 5 stories per iteration, And your developers can work on 3 items max in parallel. Then your work in progress limits are:

Column	Min	Max
Coding	3 developers * 1 = 3 Stories	3 developers * 3 = 9 Stories
Testing	2 testers * 1 = 2 Stories	2 testers * 5 = 10 Stories

Feel free to adjust this values to reality later. They need not be perfect on a first guess.

Blocked items should be visualised by card color. Next to the other issues. You can add an additional quick filter for a blocked item task force to show just blocked items. You can e.g. flag an issue or use a custom field for it.

Personally I would not set all, which is blocked in an own swimlane as you would do on a physical board. A filter, which hide / show only blocked issues will do the same.

How to solve bottlenecks

There are tons of articles, explain this very deeply. Here is just an example of an Andon Cord, which is used in productional business to react on problems or bottlenecks.

1. Stop progress and build a task force, which handles the bottleneck.
2. All participants (or at least a task force) investigate why there is a bottleneck.
3. Make the bottleneck dissappear:
   • Limit WIP before the column
   • Increase resources in the column with the bottleneck
4. Review the root cause of the problem and set steps to resolve it.

Personally I made good experience with WAR issues in Jira (or a written WAR review document). Writing them in Jira as issues has the advantage of making them searchable and easy connect them to follow up tasks or other incidents. Here is an example of such a document..

Pull Principle

You cannot see which feature is ready and which is still in work in a column in Jira.

I saw it in most teams, that tasks are assigned to people - I guess to avoid that no one is working on it. But in fact, even if it is assigned to a person, this person might not work on it, because s/he is working on a competing item - you loose visibility due to will of controlling.

Pull means: do not assign cards to people. Let them assign them to themselfes. Jira has even a link for it - so popular is it. If you do not believe me play this game with six or more collegues:

• You have one consumer, who should work on the items/requirements.
• You have at least fife people playing the producers, who deliver the items/requirements.
• The items are spreaded randomly in the room - best is to use more items than producers (pencil, rubbers, paper, …)
• Producers may carry only one item at a time.
• The task is to bring all items to the consumer - as fast as possible.
• Do not forget to blame the consumer in case you need to wait too long.
• Start on GO - What you see is PUSH

The second time do not do anything. Let the consumer fetch all items without your interaction. Maybe help, if an item is overseen or tell in advance, which items are most important. - This is PULL.

Then decide which one works better. OK this example is simple, but do you think it is getting better, when you add complexity?

How is pulling done physically

A Kanban board has subcolumns: work and pull. There no need to assign it to a special person. If it is work someone is doing things on it. If it is in pull, it is available for the next one.

The blue buttons are worked on, where the red one is available for being tested.

The blue buttons are worked on, where the red one is available for being tested.

How is it done with Jira

Do not assign an issue by default to anyone. Set it to unassigned. It will still be visible in your planning rounds. Instead of saying “I assign it to …”, say “I like this one to be done, it is important because of …”. The column indicate, which role should take it and if it is still there in your next planning round, you can ask why nobody is working on it.

Define:

• An unassigned item in a column is ready to work on.
• If I decide to work on an item, I Assign it to me. Now management knows, it is in work or at east reseved to someone.
• If an item is done, move it to the next column and set it to unassigned.

This way every coder, tester, analyst, … knows it is available to take and in the comments the status is seen. In case you are aware it does not work, take a look on your cycle time and error rate :-).

Moving cards

You do not know when an item is ready and may be move to the next column.

Everyone should know when a card is moved from one column to the other. Best is if it is intuitive, but that is mostly not the case. Therefore provide a checklist for each column transistion. This is called Definition of Done - and yes there is a definition of done for each column transition.

Below is a partly template of our workflow, which can be copied into each issue:

Column	DoD Checked	Details
Exploration
…	(/)
Development
…	(/)
Coding	(/)	implementation works
	(/)	unit tests green
	(/)	available on 1st testing stage
	(x)	testdata is known
Testing	(/)	Acceptance Criteria Met
		Documentation is finished
	(/)	Loadtests performed
	(off) / n.a.	Security review done
Cleanup		List is linked here
Testing
…

This can be a huge list depending on your workflow. Find a way which fits your needs best, but each column on the board should have its own definition-of-done defined.

These definitions must of course be visible to all project members.

How is it done physically

Depending on how many DoD you have, you can place it in the teamspace as a wallpaper with bullet points.

Maybe you have the most important three rules for your part of the work visible on a wallpaper and the details in digital form available - e.g. in a Wiki.

How is it done with Jira

The acceptance criteria are not directly connected to Jira. If you are a remote team or want to use a digital variant, place the defintion of done list in your wiki and include a copy of the DoD in your jira issue. Depending on the amount of DoD, this could be a link or a direct copy.

Metrics

Metrics are nice. They can make you happy, when you see yourself improving on changes. And they warn you, when it is getting worse. Don’t be shy and show your numbers.

Kanban Metrics based on the book Accelerate

A Kanban board support you to get two type of relevant metrics:

1. Cycle time: Cycle time is the central metric on a kanban board. It is the time an issue needs to move from left to right. If you have too less status here, you cannot say if there is a bottleneck in coding, testing in your release pipeline.
2. Error rate:
   • Originally the error rate is the numer of outtages (not regular bugs), which are caused by changes. See the image above: this could be depending on your definitions number of blocker bugs during this iteration / closed stories of last iteration - even if this is not very accurate.
   • With view on reducing cycle time a different view might be usefull as well: The number of times an issue transition into a backward status, e.g. you give an item to coding, and the requirements are too bad, you put it back to analyse requirements column. The transition counter rise on analyse requirements and you measure a problem in requirement engeneering. Transisitioning backwards is probably unexpected work in the targeting column, which should be avoided (the same way bugs should be avoided).

How it is shown on a classical physical board

Cycle time can be tracked quite easily: Just note the date, an item appears first time on the board and note the date it arrives in the last column. Track the difference and you can calculate the mean cycle time.

For the error rate, just add a marker on the card, each time it is moved backwards. Track the recorded data externally an run some analytics on it.

How it can be done on a Jira board.

Cycle Time: Jira is very strong here. It records a transition date for you, so you get a realtime analysis for each ticket and each filter:

Jira Controlchart (https://philippe.bourgau.net/my-ultimate-jira-personal-kanban/)

Error Rate: I think Jira has no built-in support for this, because it depends heavily on your workflow. I suggest to export the data and calculate the metric outside of Jira.

And if it is still too many items …

The build swimlanes. The typical lean software developement swimlanes are:

1. Expedite for items which should be resolved quickly due to time criticality or a high risk or business value.
2. Unsure value if the business value cannot be set.
3. Default for everything else

If you have too much items on your board - and changing team or iteration size is not an option, you can try to add new swimlanes instead of the default lane:

• by Epic
• by responsible role (e.g. using the Component field or a custom label)
• an own lane for technical doubts
• an own lane for blocked issues

Please take care, the swimlanes must not trigger different workflows or make issues move backward by default. A Kanban issue moves from left to right always, it may surely step over a status but should normally never go back.

Resources

• Poppendieck, (2003) Lean Software Development: An Agile Toolkit. Addison-Wesley Professional
• Bleß, Wagner, (2020) Agile Spiele kurz & gut. O’Reilly
• Pull-Prinzip für Kanban-Boards in Jira
• weighted shortest job first
• blog entry: my-ultimate-jira-personal-kanban
• blog entry (DE): Pull Prinzip für Kanban Boards in Jira
• detect and handle Bottlenecks