A Kanban Task Management Approach for Jira
Let’s assume you work in a small team, and you have to get things done — whatever that is. You heard about Kanban, and someone at your company told you that you might use a Jira Kanban board for it since your team members are spread all over the world.
This article is part of my series on Competence and Discipline: The Pillars of Excellence, where I try to share my know-how with others. Know-how translates to the dimension of competence. So here, you can learn some good practices[1] for implementing a basic Kanban board for task management in Jira. You can learn the following:
- A fundamental Kanban approach for tasks including the Jira configuration
- An alternative way for using sub-tasks as checkboxes
- Which issue fields are necessary and how to fill them in effectively
- How you can use Classes of Service and Rank for prioritization
- Understanding the terms commitment point, upstream and downstream
- How to use failure demand
First Things First!
To be honest, I don’t think Jira is an ideal tool for working with Kanban boards. There are better players like Kanbanize, SwiftKanban, or Kanban Zone. However, the reality I often face is that most companies use the market leader for ticketing tools — and that is Atlassian Jira.
As I said, from my point of view, Jira is a ticketing tool with some (agile) functionality built on top — like what Jira calls Scrum boards and Kanban boards, originating from the so-called GreenHopper add-on. But still, Jira remains a ticketing tool at its very heart. For example, Kanbanize organizes everything around boards. Instead, Jira manages everything around issue types. Or, let’s say, “tickets.” Both approaches have their pros and cons. However, Kanabanize offers more flexibility in board design.
In addition, at the time being, it seems like Kanban is not such a big thing in Australia. As Atlassian is an Australian software vendor, the Kanban implementation of Jira lacks some basic features. For example, I miss multi-column WIP limits, multiple sections per column, or an aggregated view for a multi-level Kanban system. I also miss an appropriate set of analysis tools like cycle time scatter plots, cycle time histograms, Monte Carlo simulations, or mature cumulative flow diagrams.[2]
However, since I always try to set up Jira with its native feature set only, I have to figure out how to configure Jira pleasingly. And there are some good practices, which is what this article is about.
Setting Up the Project
Let’s say we are using the cloud version of Jira. In that case, we need to set up a Kanban project which is company-managed. However, we are going to change the Kanban project template.
The issue types we need for our Jira project are Task and Sub-task. Since I am not writing about setting up a multi-level Kanban approach in this article, I am not taking Epics into account.[3] Thus, the issue types of interest are defined as follows.
- Task issue type
Tasks follow a Kanban-oriented approach. A task states WHAT should be done, WHY it should be done, HOW it should be done, and WHO should do it. - Sub-task issue type
Sub-tasks are set up so that they act like tickboxes. A sub-task should never be seen as additional work on top of a task. Instead, you should use sub-tasks to structure the work needed to achieve the goal of the parent task.
Sub-tasks in a Nutshell
To make things short before we come to the central part, the workflow for sub-tasks is straightforward. It is designed so that sub-tasks act as somehow advanced tickboxes.
Instead of just ticking a box by setting the sub-task to DONE, you can also show that a sub-task has been started by using the status DOING. With DELEGATED, you can clarify which sub-task is under the control of someone else or an external party.
Please note that this way of working with sub-tasks has nothing to do with Kanban. You may set a sub-task to DONE, and afterward, you open it again by setting it to TO DO. As I said, with sub-tasks, we are emulating tickboxes with some extra features. And that’s it.
It is also entirely different from what you may know from a Scrum board, where your Sub-tasks might follow the same workflow as your parent issue types like user stories. With the approach presented in this article, sub-tasks will not appear on our task board at all. We will only use them in the issue detail view of our task issues.[4]
The only thing to mention about this workflow is that when moving a sub-task to DONE, the workflow asks to set a proper resolution. All other transitions remove the resolution from the sub-task.
The issue fields of a sub-task should be as standard as it gets. You may only use the Summary field and the Description field. Don’t overengineer with sub-tasks — but at least define a clear title; in the same way, I will describe it later for the task issue type.
The Task Workflow
First, let us talk about the workflow for tasks. I don’t like workflows that have a lot of transitions from one status to another. Therefore, my workflows mainly use what I call “All-transitions.”
I recommend not using the status dropdown selector of the issue view when having a workflow that uses All-transitions only. Instead, always use a Jira board when transitioning issues. Since Kanban asks you to move issues from left to right, the board shows you which status comes next. Most of the time, the dropdown is not sorted according to the board. Consequently, the risk of moving a task to the wrong status is increased.[5]
However, the more important reason for using the board is the following. Using the board for transitioning tasks is essential to comply with WIP limits. When using the dropdown, you do not know if you will break a WIP limit with this action. When using the board, you always see how many issues are in a particular column. Thus you instantly know if your transition will break a WIP limit or not.
In line with the sub-task workflow, the workflow asks to set a proper resolution when moving a task to DONE. All other All-transitions remove the resolution from the issue. You also see that the status ARCHIVED is only reachable via DONE, ensuring we set a proper resolution.[6] Additionally, ARCHIVED has a self-transition that allows you to change the resolution if needed.
Issue Fields for Tasks
For tasks, I think the following issue fields are essential.
- Summary
The title of a task. A short imperative statement of what must be done. - Description
Describe the WHAT and WHY in more detail, so everyone has the same understanding of the task. Use a template to ensure the quality of information. - Class of Service
Use the idea of risk profiles for prioritizing tasks. - Due Date
Whenever the issue field Class of Service is set to Fixed Date, the due date of an issue becomes relevant.
Summary
A good title always helps you have a first idea of what is in and out of scope. I often see issues that only consist of a single noun. But a noun alone does not say much.
Since we are talking about tasks, ensure that you write the title as an imperative that holds a main verb. The main verb is a verb that forms the substantive core of a sentence and can serve solely as the predicate of a sentence.
For example, “Milk” is a lousy title. “Buy milk” is a better example because it states the main verb “buy,” so you know what to do with the milk. “Buy milk for breakfast” is an excellent example because it also provides some context, and it is still short. More information should be stated in the task’s description.
Do you laugh about the milk example? If so, I can tell you that I have seen many people just stating “Milk” as the title. This is where not just the dimension of competence comes into play but also discipline.
Description
If you can’t explain it simple, you don’t understand it well enough.
Albert Einstein
We should try to write down our thoughts in the most concise prose possible and avoid bullet points whenever we describe something. I recommend using templates to fill in. A great template always covers the questions of WHAT, WHY, HOW, and WHO. Thus, your description field should contain the following headlines.
- What?
Describe what should be done without naming the reasons for it. Use prose in active voice. - Why?
Make clear what’s the exact reason for the task. Use prose in active voice. - Acceptance Criteria
Define a bullet point list of criteria. Each criterion should be a short sentence. Acceptance criteria are used to make the WHAT more concrete and testable.
I recommend avoiding such things as the MoSCoW method when defining acceptance criteria.[7] Thus I say every acceptance criterion has to be a must-criterion. From my experience, everything defined as should or could becomes irrelevant. Even worse, if you don’t do a could-criterion, you might generate some confusion when someone else tries to verify the acceptance criteria. However, what you can do is define acceptance criteria using won’t. It may help to define what is in scope and out of scope clearly.
The question of WHO should be covered by the issue field Assignee. It should be set by the person who pulls the issue when she starts working on it. HOW can be covered by defining a set of sub-tasks that describe all things that have to be done.
You may have heard the saying that “a user story is an invitation for a conversation.” I think this is ultimately true for every issue we define inside Jira — and so it’s true for tasks. Although you are using a template, ensure that you have acts of communication around each Jira issue.
Others may cross-check if the information is complete and understandable from their point of view. Even better, working in pairs or groups is always a great idea when defining Jira issues. And, of course, a template helps you have more profound and more directed communication, leading to a better understanding for everyone.
Class of Service & Due Date
Classes of service and the sort order within a column are the Kanban way to prioritize. There are four standard classes of service called expedite, standard, fixed date, and intangible.
A class of service is a set of policies derived from a so-called risk profile. A risk profile is a two-dimensional graph with the dimensions (business) impact and time. It means the risk profile asks for how the (negative) impact develops over time as long as a task is not done. The area under the line is the total impact or cost over time. Or, in other words, the cost of delay (CoD).
The policies applied to a given class of service must ensure that you can prioritize in the right way. Or, saying in a more Kanban way, that your team always pulls the right task at the right time. An example policy might be that you are allowed to break your WIP limits when a specific class of service is set. And that is where we come to our first class of service called expedite.
For the class of service Expedite, the impact is very high right from the beginning. Consequently, tasks with this class of service must be processed immediately. When you set a task to expedite, ensure that you shift resources so that this task gets done as fast as possible. And, of course, an expedited task should be allowed to break the WIP limits.
If you have multiple expedited tasks, the highest priority has the task with the most significant impact. You might also consider how long it may take to get a task done. Strategies like “Shortest Job First” may help at this point.
However, you have won nothing if you start setting every task to expedite. You will just bring your Kanban approach ad absurdum. As Karen Martin said:
When everything is a priority, nothing is a priority.
Karen Martin, The Outstanding Organization
Fixed (Delivery) Date is quite similar to Expedite. The difference is that the impact is very high from a defined point in time in the future. A good example is always a legal regulation that comes into effect at a particular time. Consequently, you must ensure that the task gets done right before it comes to effect.[8] On the other hand, it can be considered a waste if you perform the task too early.
Of course, when using Fixed Date, you must also define the date. The best issue field for that is Due Date, as it is the default date field in Jira.
Fixed Date has a similar problem like Expedite. Some organizations tend to ask for a due date for every task. They plan their projects with endless GANTT charts. Such up-front planning works against the natural flow of work. By doing so, organizations step into the Trap of Determinism[9], and it bears the high risk that you will end up in a situation of high WIP and a lot of task switching. Thus, as a rule of thumb, you should always try to set Standard as the class of service.
Standard is the most common class of service. Usually, the impact starts to rise progressively until a specific point in time, and then it digressively approaches a certain maximum.
For instance, your task is to pay a bill. Over time you will receive more and more reminders, and the total of the reminder fees will increase but after some time in a digressive way. However, the maximum of reminder fees is reached at a certain point, and you simply go to jail. It is the point where the S-curve reaches its maximum.[10]
Consequently, the S-curve of this risk profile allows you to decide in which order you want to deliver your features. A faster rise of the line to a higher overall level should result in a higher priority.
However, I recommend not to overengineer: In most cases, it is almost impossible to predict the exact course of the curve because it is a complex thing to do, not a complicated one. However, risk profiles offer a great way to think about priorities.
Intangible is the suitable class of service if you have no idea what class of service to set. The dotted line followed by the solid line clarifies that, out of a sudden, it may also become an expedite — a typical hockey stick development.
However, I recommend ignoring this class of service and using the class of service Standard instead. Some people use Intangible to make clear that additional investigation is needed. From my perspective, if it is too difficult to find out anything about the impact, it might be a waste of time to invest in further analysis. Therefore, go with Standard.
The issue field Class of Service should be implemented using a single selection dropdown field. Additionally, it should never be empty and set to Standard by default. It means you must create a field configuration for the issue type task. Change the issue field Class of Service to be required.
In addition, you must set up a context for issue field Class of Service where you set Standard as its default value.
Now, whenever you create a task, the field Class of Service will never be empty.
Intermezzo: Kanban Makes Use of Pull Systems
To make that clear, we are talking about Kanban here. It means that you only move issues in one direction: from left to right. You also never push an issue to the next column nor assign it to one of your team members. Instead, Kanban asks for pull only. Meaning a team member who wants to take over a task takes a look at a particular column and decides which task she wants to pull to the next column, according to the well-defined pull policies, and handles it accordingly herself.
To ensure pull, you must use so-called waiting queues — otherwise, you automatically push whenever you move a task from one column to another.
Pull together with WIP limits is a powerful tool to achieve constant flow. Constant flow, in turn, is the basis for a stable system and a stable system is the enabler of the predictability of completion dates (not cycle times!). Without a stable system, it is pointless to practice probabilistic forecasting using the Monte Carlo Simulation statistical method. Those methods simply do not work without a stable system.
And this is what the whole board design I now present aims at; the foundation for a stable system.
Board Design and Mechanisms
The image above shows the board design. I just mapped each status to a single column of the board. In addition, I like to use Jira’s backlog function. Thus, the status BACKLOG is mapped to the Kanban backlog column.
I also put in some example WIP limits. Keep in mind that there is no rule on what WIP limits are best for you or your team. Having reasonable WIP limits in place at a given time depends on team capacity, size of work items, the complexity of work items, and many other factors. Since those factors constantly change, adjusting WIP limits to find the optimal flow of work is always an ongoing process when doing Kanban.
However, let’s get back to the implementation in Jira. According to our definition of sub-tasks, which should be used to structure the work of the parent task, we must exclude them from the WIP limits. Otherwise, we would count the same work multiple times.
So far, so good. Let us now discuss the details of the columns and what mechanisms are behind them. Noteworthy, in Kanban, you should have a set of done criteria, also called the definition of done (DoD), for each column. Some may also call that quality gates. In practice, it means that you have some kind of checklist for each column of what you must do before you are allowed to pull an issue to the next column. It aims to improve your flow by reducing rework, or failure demand, in the long run.
Backlog
The backlog is a sorted list of all issues that have been created and not further processed. A sorted list means that we use the Rank feature to sort tasks according to their priority. Consequently, the most critical task stands on top. The second important task is on the second position, and so on.
You decide on the position of a task based on its class of service and cost of delay relative to the other tasks in the column. Of course, this applies to any other column as well. Therefore, I do not use Jira’s Priority issue field at all. I leave the prioritization of a task to its class of service in combination with its position in a column.
However, for the Backlog column, we do not need a WIP limit. The backlog is allowed to hold as many issues as you want. Anyways, I recommend making it clear that all backlog issues have a meaningful title after they have just been created. Otherwise, your backlog will become more and more like a vast junkyard. And finding the right tasks in a junkyard consumes a lot of energy and time.
Definition of Done
- The task has a meaningful title that describes the action to be performed
- The title holds a main verb
- The description field is filled out according to the template
- The correct class of service is set
Option
The column Option is a sorted list of tasks that are ready to be worked off and might be worth getting started. However, anything is still optional because at this point, the team has not committed to work it off. In Kanban we call that the commitment point.
Having the commitment point between the columns Option and Next means that when transitioning a task from Option to Next, your team commits that it will process the task as soon as possible. In short, it’s not optional anymore.
I always use a relatively high maximum WIP limit for the column right before the commitment point. You can consider this column your backlog of tasks that are ready to be worked off. I also align the minimum WIP limit with the maximum WIP limit of the column right after the commitment point. In my example, the minimum WIP limit for the column Options is four. It is the same as the maximum WIP limit for the column Next. However, it must not be the same as in my example, but both WIP limits should be somehow connected.
Setting the maximum and minimum WIP limit in that way ensures that there is enough work for your team ready. The mechanisms around the commitment point are crucial to having a stable system. Invest some time in understanding how both columns work together and why they stand in context with each other.
Definition of Done
- All team members have the same understanding of what has to be done why
- All team members understand the task’s priority
Next
You and your team cannot ignore any of the tasks in this column. Once the team replenished new tasks to the column Next, they committed to getting them done. And not only that but to get them done as soon as possible.
When you come from a Scrum world, you know a similar mechanism like moving backlog items from the product backlog to the sprint backlog. You can consider everything before the column Next to be your Product backlog. In Kanban, we say, everything before the commitment point is the so-called upstream: you must bring work items up the stream by defining them to float (flow) down the steam.
The column Next works somehow as your sprint backlog, followed by the sprint board. All of this, beginning with the column after the commitment point, is called downstream in Kanban: the work is well prepared, so working it off feels like floating (flowing) down the stream. Thus, the downstream is like a sprint in Scrum, but it’s more like a long-distance run at a healthy pace.
Accordingly, with Kanban, you are not filling the column Next in fixed iterations. With Kanban, you are doing a replenishment in an ongoing way using so-called pull signals. Pull signal means that you have to pull new work into the system whenever a minimum WIP limit is in danger of being broken or a column is running empty. Setting a minimum WIP right after the commitment point can ensure a constant flow of work because there are always tasks available the team can pull when there is free capacity.
Consequently, for the column Next, I use a relatively high maximum WIP and a minimum WIP that is roughly half of the maximum WIP. The minimum WIP limit ensures that the pull signal does not come too late. The maximum WIP limit ensures that you do not do too much work up-front.
There are no done criteria for this column since it is just a waiting queue. However, if you see that some issues need further description or adjustments, do it. Waiting queue does not mean that you are not allowed to do anything at all.
But what you should not do is start working on the task when it’s still in the Next column. It would mean that you cheat against your WIP limits. And that means that you are not able to analyze your flow of work properly, and you cannot identify problems in your way of working.
In Progress
In Progress is the column where the actual work gets done.
I never put a minimum WIP limit here since this may lead to a situation where your team members are just held busy. You don’t want to be busy; you want to be productive. That’s a significant difference.
Of course, a maximum WIP limit is mandatory. You can take the rule of thumb that you start with a WIP limit of n-1, where n is the number of team members. Your WIP limit should not go above this number. Instead, try to reduce it over time.
Within this column, it is essential to visualize if an issue is blocked. When using a physical board or a flexible digital whiteboard like Miro or Mural, I would have sub-sections for External Waiting and Internally Blocked tasks. Tasks inside Internally Blocked must count into the WIP limit. For External Waiting, you may decide. However, I would count them in and see how it works out.
With Jira, we have a problem here. We are not able to configure our board to have these sub-sections. Of course, you can map multiple statuses to a single board column, but once you have moved an issue to one of the statuses, you cannot change the status using drag and drop on the board.
Therefore, the options that may make sense are:
- Add statuses and map them to the column In Progress
You add the status External Waiting and Internally Blocked to the workflow. Map the two statuses to your column In Progress. Use the status dropdown field to change the status accordingly. You may then use card colors that show the information on your board. Or you may use swimlanes. The disadvantages are that Jira does not sort the colors automatically to separate sub-sections, and the swimlanes are shown for all columns. - Use labels
Use the labels external-waiting and internally-blocked. You can then use card colors or swimlanes as before. However, labels have the disadvantage of adding and removing them manually. It might lead to confusion over time. - Use the Flag feature and add a comment
Jira boards offer the function to flag a card. When flagging, you may add a comment that states if the issue is waiting for an external party or is blocked internally. However, you cannot visualize this distinction on your board. You only see that an issue is blocked.
All in all, I prefer the third option of using the flag feature. It’s easy to do, and in most cases, it’s sufficient. However, when it comes to the point where you want to analyze your workflow more deeply, all three approaches are sub-optimal.
Definition of Done
- All acceptance criteria have been met
- All sub-tasks are done
Waiting for Feedback
With this column, you ensure that you also get positive feedback from the requestor of the task. If you are the requestor of your own task, you may take your time to cross-check again if everything is correct. Or better, ask someone from your team to do the check.
I recommend having a high maximum and no minimum WIP limit for this column. It takes into account that the process of providing feedback may not be under your control; thus, some tasks may stay for a long time in that column.
Definition of Done
- All acceptance criteria were approved by a person who did not implement the task themselves
Done
You did it! All work has been done. Select a suitable resolution and have a cup of good coffee. No WIP limits or done criteria are needed here.
Archived
I have to tell you a dark secret: I don’t like the idea of the release button on Jira’s Kanban boards. Thus, I configure the boards so that they behave similarly to boards I have used with Kanbanize.
Meaning, on the one hand, we have the last column named “Move to Archive,” where we mapped the status ARCHIVED. On the other hand, we configure our board filter to ignore all tasks set to the status ARCHIVED.
It has the effect that whenever you move an issue to the column “Move to Archive,” the task disappears from your board. That allows you to decide flexibly which tasks Jira should display on your board and which are obsolete.
To complete this configuration, I permanently remove the board’s sub-filter, and of course, I disable the board feature where Jira hides issues older than X weeks.[11]
Handling Failure Demand
Still, we have not discussed the following important question: what happens if a task is in the column Waiting for Feedback and it appears that something was done wrong or is missing? The usual reflex of people is that they move the task back to the column In Progress.
Uh-oh, bad mistake.
Keep in mind that you are doing Kanban, and you are only allowed to move tasks from left to right. So what to do?
The solution for that problem lies in what the Kanban community calls failure demand. It means that you and your team generated additional work (or demand) because you did not appropriately do the work during the normal process.
You might say that you can create another sub-task to cover that problem. I strongly contradict this! Instead, you should leave the task in the column Waiting for Feedback, highlight it, and create another task that describes the things that must be reworked.
Important: the original task stays in the column Waiting for Feedback as long as the new failure demand task is set to the column Done. Then you can remove the highlighting from the original task and recheck its acceptance criteria.
To highlight the original task, I would ideally set up a sub-section in the column Waiting for Feedback named Rework Required. Since we know that sub-sections are not possible in Jira boards, I suggest using the Flag feature in combination with a comment. Then you need to create a new task that runs through the same process as the original task. At best, you use an issue link to connect the original task with the failure demand task.
You also should distinguish failure demand tasks from the standard tasks. It helps you to do further analysis. Knowing how much failure demand you and your team created over time and how this hindered your team from working on new tasks helps you improve your system.
The following options for implementing this mechanism make sense to me:
- Task with label
You create a new task and add the label failure-demand to it. Here you are free to select the class of service for the task. It is easy to do. However, you have to find a way on your board to make these issues visible. Card colors and swim lanes may be your weapon of choice. - An additional class of service
You may add another class of service called Failure Demand. Then you may define policies similar to Expedite. You may specify that Expedite still trumps the class of service Failure Demand — or the other way around. Of course, card colors and swim lanes help visualize this as well. - An additional issue type
Last but not least, you may define a new issue type called Failure Demand. By selecting a prominent icon for this issue type, these issues are already visualized on your board well.
I suggest going with the third option. A separate issue type provides the most degrees of freedom. You can use the existing classes of service, define individual screens for it, and specify a tailored workflow for failure demand issues. However, using the task workflow for these issues should also be sufficient.
All this has just one goal: Handling failure demand with urgency. It makes sense because it aims at the Kanban rule “right before left.” It can also be translated to “stop starting, start finishing.” Remember, you can move the original task only if all failure demand has been worked off. Until then, the task stays in your column Waiting for Feedback and counts to the WIP of the column.
Indeed, the failure demand task counts to the WIP of its current column as well. It should also make use of classes of service in the same way as a task. Thus do not forget to add the issue type to your field configuration scheme and the context of the custom field Class of Service.
This mechanism ensures that you feel the pressure to get things done before starting new work. And that is a crucial step toward system stability and predictability.
The Discipline of Kanban
Now that you have read this article, you might have some ideas you want to try out. Well then, set up work items (or issue types) and workflows and adopt some of the good practices you have found in this article.
As I said at the beginning, I tried to cover the domain of competence. However, when you and your team are new to Kanban, you will most likely experience that WIP limits are constantly broken or, even worse, that nobody cares. Then your problem might not only be on the competence side; it might also be a problem of having a lack of discipline.
Your lack of discipline is probably a systemic problem that needs a lot of discipline to be analyzed and mitigated appropriately. You need to do what Kanban asks you for: analyze the root causes of your problems and try to solve them through a process of evolutionary change. That is the very heart of Kanban: it’s an analysis tool to enable continuous improvement.
Therefore I recommend hiring an experienced coach who teaches you Kanban and who may also act in what is commonly called a master role — such as the Scrum Master for Scrum. From my point of view, this is a significant success factor when establishing the Kanban method. Keep in mind competence and discipline are mutually dependent.
Footnotes
[1] I do not like the term best practices since best is absolute. Most of the time, there are many ways things can be done. In complex domains, best practices cannot exist because you can never predict the outcome of a particular practice. Thus, there are only good practices because there potentially is a better practice you don’t know. Read my article Leadership: The Three Traps of the Newtonian Mindset to learn more about complexity.
[2] Of course, there are add-ons in the marketplace like Kanban Combined WIP or Dan Vacanti’s ActionableAgile Metrics. These add-ons provide a lot of functionality, and I understand why Atlassian leaves some topics to external vendors due to flexibility. However, compared to Jira’s Scrum features, the Kanban implementation should be improved by Atlassian.
[3] However, I like having a two-level Kanban system where epics act as work packages containing a set of tasks. But with this article, I want to describe the very basics of how to set up a somehow basic Kanban board in Jira — and that’s it. I have planned to write an article about a two-level system with Jira. I will link it here as soon as it is published.
[4] When using a current Jira Server/Data Center version like 8.13.x, it is not that easy to let Jira display the sub-tasks in the issue detail view of your Kanban board. You must do some nasty configuration on your board. First, you need to install the add-on Jira Scriptrunner to extend your JQL by the function issueFunction. Then, define the board query as follows:
project = TASK AND issuetype IN (Task, ‘Failure Demand’) AND status != Archived OR project = TASK AND issueFunction in subtasksOf(“project = TASK AND issuetype IN (Task, ‘Failure Demand’) AND status != Archived”) ORDER BY Rank ASC
Next, set the board’s sub-filter to “issuetype IN (Task, ‘Failure Demand’)” so that the board itself does not show the sub-tasks. Finally, map all status of the sub-task workflow to the columns of your board — even though they will not be displayed on the board.
[5] Sad but true, the opsbar-sequence transition property does still not work with Jira Server/Data Center (see JRASERVER-40540). However, I find it annoying to sort a list by typing in numbers. Therefore, I avoid this type of configuration.
[6] Of course, you can use an All-transition for reaching the status ARCHIVED as well. However, I like to be a little bit restrictive at this point since it forces you to think twice if an issue should be archived or not. From my experience, it’s always a great team experience when you sit together and archive (or trash) the tasks of your Done column — the whole team experiences what they have achieved over time.
[7] Learn more about the MoSCoW prioritization method in this Wikipedia article. Since MoSCoW stands for must have, should have, could have, and won’t have, I never understood why the acronym is not defined as MuSCoW — even though I am aware of the name of the Russian capital city.
[8] Predictability becomes essential when you have to deliver issues with a fixed delivery date. You should be able to say when to start with something to meet the delivery date.
[9] Read my article Leadership: The Three Traps of the Newtonian Mindset and learn what I mean when mentioning the Trap of Determinism.
[10] It might not be an optimal example for explaining the S-curve of the standard risk profile. However, I had a lot of fun when this example came to my mind.
[11] The feature where issues get hidden from a board later than X weeks is sometimes nasty since it relies on the issue field Updated. Whenever you have some issues left that are not yet part of a release, but you do, for example, a bulk change to a lot of Jira issues, it can be that out of a sudden, a lot of issues appear on your board.
Book Recommendations
- Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson - Kanban from the Inside
Mike Burrows - Kanban Change Leadership: Creating a Culture of Continuous Improvement
Klaus Leopold - Practical Kanban: From Team Focus to Creating Value
Klaus Leopold - Actionable Agile Metrics for Predictability: An Introduction
Daniel S. Vacanti - The Outstanding Organization: Generate Business Results by Eliminating Chaos and Building the Foundation for Everyday Excellence
Karen Martin
