Seven boards and one task
Filter – select everything with labels about incomprehensibility. The grouping is based on the nature of incomprehensibility. Needs detail of clarity, Needs more focus, Needs debugging details – go to StackOverflow and see how this is done. There is no need to reproduce them one by one, since the scenarios for the occurrence of problems are very different, but you can get inspiration.
The board can help in forming a pool of tasks for the next grooming. Those that have been lying here for a long time without moving are candidates for cancellation.
Planning and tracking
▍Ready To Go
A task that passed through the funnel and did not fall into the sump Unclear Tasks, ready to go to work. Such tasks can be displayed on one board and sorted by importance, complexity, and urgency.
The columns responsible for statuses are absolutely not relevant here – the displayed tasks are in the backlog. But JIRA doesn’t know any other way. Although the concept of quadrants with Value-Effort intersections would look very good here. We have what we have, so we are swimlanes again.
The groups are defined as follows:
Low hanging fruit – easy and valuable tasks;
Grand prix / Major target – valuable, but difficult;
Chicken feed / Afterwards have a look at – not very complicated, but not particularly necessary;
Dead ducks / Discuss before assignment – not meaningless, but with weakly expressed value, and relatively complex.
Here you can take into account the tracker’s native “Priority” field, so that you can force tasks to move to the next group. It was rated as Chicken feed, but the management insisted on urgency – we are not changing the rating, but we are raising the priority to Critical. A problem of questionable value ends up in the top.
In a more dense task management system, the described scenario would probably be better suited to shift class of service. For the current small team with a not very powerful flow of tasks and a rather sluggish influence of business on priorities, the introduction of the “class of service” attribute looks somewhat far-fetched. In another situation it might have been more appropriate.
A filter by labels is equivalent to negating the entire combination of filters from Funnel. That is, we select here tasks that have received an assessment of complexity and value, are not considered muddy or rotten, with a designated specialization and an established priority.
Ready to go? Welcome to the board!
Additional filter: if the task is in an epic, then epic should be in work. Sketching tasks into an epic in advance is a normal activity, but there is absolutely no need to tackle these tasks ahead of time. The wording of this filter is not the most obvious: "Epic Link" is EMPTY OR "Epic Link" is not EMPTY AND issueFunction in issuesInEpics("statusCategory = 'In Progress' and filter = <Id базового фильтра задач вашего проекта>")
When a task has an Assignee, it can be removed from this board. From Ready it has clearly progressed to Go.
For convenience, it is worth creating several quick filters based on specialization. So, anyone who wants to find a small task, for example, in C# or writing documentation, can do this in a couple of clicks. And you won’t have to distract the manager for this. All ready-to-work and free tasks are displayed on the board Ready To Go, in it we click the quick filter with the specialization of interest, then we see the answer to our question. Here are the more difficult ones, here are the simpler ones, here are the more important ones, here are the secondary ones. Take it and do it.
▍ Epic progression
Issues are often grouped into epics. As the tasks are implemented, I would like to understand how far we have progressed towards closing the epic.
You don’t need a lot of speakers; the same set as in Squad Kanban. Grouping by epic. Simple and clear.
There are no filters by labels. If the task is unclear, then there is no need to include it in the epic.
JIRA boards have an option to “hide completed issues N weeks after closing.” In other boards this may be appropriate, but here it will interfere and reduce visibility. I recommend disabling the option, but you will have to make a slightly more complex general board filter than usual. If the closed task belongs to an unfinished epic, then let it be displayed. And if the epic is completed, then neither the epic itself (the horizontal bar) nor the tasks from it are needed for viewing.
Some trackers (but not JIRA) are able to show how many issues there are in an epic and the number of completed ones. It's comfortable.
Also, for convenience, it is worth adding a quick filter that selects only epics in the work. Obviously, there can be no progress on epics that will be dealt with in a year today. As with those completed long ago. You can also add quick filters to detect blocking tasks and for blocked ones.
▍Initiatives
Since epics exist, that means they need to be managed. The life cycle of epics does not have to be as complex as that of tasks. Often there are only three statuses: To Do, In Progress And Done. The needs for visibility and dragging from one column to another are the same as for tasks and bugs. However, none of the boards discussed above satisfies this need.
In task management, one can distinguish the essence Initiative or line of business. Epics do not live in a vacuum, not for their own sake, they are aimed at improving specific products, at developing automation of one or another line of business. To solve a class of problems. Hierarchically, epics may not be related, but in context it is often appropriate to combine them, since directly or indirectly each epic relates to some area of activity, a vector of application of the team’s efforts. Therefore, it will be successful to unite such epics with a common super-essence. Directions, unlike epics, are endless. It’s not good to make epics endless – they should be limited in time, start at some point and end at some point.
The grouping on the board is done according to Initiatives. The rectangle cards here are epics. Smaller entities (tasks, bugs) are not represented in any way. The only board where you can move the epic.
Filters by labels are not relevant.
It makes sense to create and maintain a roadmap in the context of either a board Initiativesor Epic Progression. Areas of activity are not displayed on the roadmap in any way (they are endless), but can be used to group epics similar to grouping on the board.
Summarizing
Seven boards
As promised, seven boards to help a small team with an average backlog of a couple of hundred tasks:
Personal Kanban.
Squad Kanban.
Open Bugs.
Funnel.
Unclear Tasks.
Ready To Go.
Epic Progression.
initiatives.
Did I say seven? Eight.
And two more. We use poker sessions to measure the value and difficulty of tasks. There is a plugin for organizing such sessions in JIRA, but this wonderful plugin does not support quick filters. For any of the mentioned poker sessions, the task should be ready and satisfy a bunch of conditions, but the plugin returns to the beginning of this conversation and for some reason dumps out everything that is there, suggesting that you search for the necessary tasks manually. This is terribly inconvenient, and in order not to suffer, two surrogate boards have been created, which, in fact, perform the function of saved filters. So these two boards are not needed for nothing.
Well, a couple of other boards also need not columns, but other mechanics, so they are not exactly “boards”.
With a similar set of boards, auxiliary quick filters and basic diagrams from the Agile plugin for JIRA, it is quite possible to easily and effortlessly cope with the flow of tasks and a medium-sized backlog alone.
Comments
Creating a system of boards and filters is not an easy task, as is the initial establishment of order in tasks. But in the future, maintaining the relevance of boards and roadmaps does not take almost any time, does not require a synchronous, drawn-out, many-hour immersion in everything accumulated in the tracker, to find answers to primitive questions or to restore order again. Thanks to the system of labels and filters, the order in the tasks is self-maintained, and epics on the roadmap do not have to be moved eight times a day.
“It’s better to lose a day, then fly in five minutes!” – the same story.
The system turns out to be unbureaucratic, quite in the spirit Agile. Where are the labels and filters for a person, and not a person for a thousand required fields and forever unbalanced Gantt charts. Separately, I would like to draw your attention to the fact that in the proposed approach, in no scenario does the task manager have to navigate the ever-stormy ocean of a trillion tasks in a fragile boat. The full list is not displayed to the task tracker user anywhere. You can find it if you really want it, but there is no reason to regularly scroll everything from bottom to top with such an organization of work.
If the story with labels seemed too complicated, far-fetched, but there is actually only one board in the team, and the problem with loss of control focus is obvious, then I would suggest adding at least Open Bugs And Epic Progression.
The experience of StackOverflow can help you choose labels about an unsuccessful problem formulation – the guys, as they say, ate the dog on this one. So suddenly they once again came to Joel Spolsky. I also recommend wandering through the repositories of popular products on GitHub, see what label system they use to manage bug reports, feature requests, and releases.
In addition to boards, it also makes sense to have dashboards with gadgets: counters, graphs. You can subscribe to some filters and regularly receive notifications from JIRA when issues match the conditions of these filters.
So, if there is no system in the team and everything is bad in the tracker, there is no reason to be upset. Perhaps this is a good reason to experiment, find your own approach, and form your own system. But don't forget that the rest of the team members are people too. Discuss, negotiate.
Good luck in management!
Test questions to evaluate your current task management system
1
A JS programmer came to you (substitute the language that is relevant to you, and if everyone writes in the same language, then a functional block, a direction that not everyone understands) and says that he has a slight pause in tasks: one large one has gone to UAT , and it’s too early to start another big one, and asks to be given something small, simple, to do while there is nothing basic.
How much time, clicks, and how many questions will you need to ask someone other than yourself to answer the programmer’s question and give the numbers of a couple of tasks that fit the description?
Seven Boards: open Ready To Go, click on the quick filter “code:js”, look at the Chicken Feed, Low Hanging Fruit blocks. There is no need to disturb other people. You can show the JS-nick how you do it, and ask them not to bother you further with such matters.
2
The big boss loudly, persistently and aggressively conveyed to you the point of view that you do not control the situation with bug reports and for some reason very important clients have to wait “two years” for the correction of a monstrously critical bug, which has already been said ten times that it is hyper-urgent , and you are neither in sleep nor in spirit. About the bug, from the description it is roughly clear what functional block it belongs to, and that it was introduced not two years ago, but yesterday evening.
How much time will it take you, how many clicks will it take you, how many questions will you need to ask someone other than yourself in order to find a bug that matches the description, provide the clarified details about the problem and the degree of readiness of the fix? You will probably also want to prepare some kind of superficial report, an overview of the situation about all the currently unsolved ASAP problems. At a minimum, their number and the degree of readiness of the solution. How much effort and time will it take to collect this information?
Seven Boards: We open Open Bugs, we immediately see that there are ASAP bugs. Here we see whether there are any bugs filed under the epic that matches the description. We poke the quick filter if the bug relates to an understandable component. We only bother others if we haven’t found anything similar at all.
3
A project/product manager, who is not interested in digging through tasks, asks about progress on two epics. What is completed, are there any blockers.
How long will it take, from how many places will you collect this information, how many people will you have to involve, how many search queries will you perform?
Seven Boards: open Epic Progression, see the ready answer to the question asked. We explain to the manager how to enter here and how to use the quick filter to detect blockers. We suggest you stop bothering you on such issues.
![Automatic scaling of Symfony consumers in Kubernetes [Практическое руководство]](https://prog.world/wp-content/uploads/2023/05/b91d8a3e7fb5a7e17c614756d5281fe8-768x432.png)
