Update: unfortunately some parts of my original post right below are not correct, confusing or misleading - you will find a much more accurate description of my problem in my second answer to Trudy's response further below!
I'm getting crazy about this one so maybe someone can help me with this:
Kanban boards do have this great feature called "Kanban backlog".
Thanks to this feature the backlog items will not get displayed on the first column of the board. Instead you can use the "backlog area" to organise the backlog "behind the curtains"- perfect!
What I absolutely do not understand is why Scrum boards behave differently in this regard - it makes me go nuts, that I have to map a status to (usually the first) column of the board. As a result, all items listed in the "backlog area" of the Scrum board are getting displayed on the board itself as well - holy moly!!!
The backlog items should not be displayed on the board. They should stay in the background, in the "backlog area". There, only items dragged into an active sprint should be displayed on the board.
There even is a support entry that suggests, JIRA would work this way (here).
But it doesn't (and contradicts in a certain way the other support entry listed above - or at least it leaves out, that the "Backlog list or planned sprints list" will be displayed on the board as well).
Is there any way to make a Scrum board behave this way? The current behavior seems like a huge design flaw to me...
Your're right about the fact, that a sprint needs to be started first. As long as a sprint is not beeing started, the active sprint board will be empty (if the last sprint was already closed).
But once the sprint was started, any items left in the backlog list of the "backlog area" are getting displayed on the board as well. If this list is empty because you moved all items into the active sprint, you still get an empty (probalby) first column on your board.
My point is: either way you need a "backlog column" in addition to the backlog list inside the "backlog area" - whether it's empty or not.
I think you’re losing me here. In any of my active sprints I will only see the issues that I have moved into the sprint. I never see any true backlog issues in my active sprint. What I will see in the backlog page in the top section are any issues that are still in progress in active sprint. Please note I only use classic for company managed projects for my scrum projects. Maybe there is something unique and different next gen and or team managed projects. Unsure which type of project you’re using
I was wrong about one thing - you are right, it seems that the "backlog list items" listed in the "backlog area" are not beeing displayed on the board of an active sprint... I was quite sure they would be - still I do need a separate column in my board for any backlog items to be listed inside the backlog area at all (but the column stays empty in contradiction to what I stated before - sorry for the faulty info).
Please take a look at the scrrenshots attached to my answer of Trudy's post below.
Hello @Sebastian Krzyzanowski
Are you working with a Team Managed project/board or a Company Managed project/board?
With a Scrum board the board display will display all issues included in Active Sprints. If the issue is not in an Active Sprint, then it should be displayed in the Backlog section of the Backlog screen.
The Backlog screen also displays sections for Active Sprints and Sprints created but not yet started, and issues that are assigned to those sprints will show in those sections rather than the Backlog section.
The scrum workflow would typically start with all issues in a "To Do" status and in the Backlog section. You then create a sprint (on the Backlog screen) and pull the issues from the backlog into the sprint for the work you plan to do in the sprint. All the issues retain their status (i.e. To Do) during this process of populating the sprint. Then your would Start your sprint.
The scrum board is designed to show you the issues that are in Active Sprints. Those issues will start in the "To Do" status typically, because you haven't started the work yet. So, you need to map the "To Do" status to a column in your board - typically the left-most column. As you work on the issues in the active sprint, you update the status of the issue and it moves across the board.
Issues that are in the Backlog section of the Backlog screen should not be showing on the board.
Can you show us images of your board and your Backlog screen?
Hello Trudy - see 2 screenshots attached. I was wrong with the backlog items beeing displayed in an active sprint - BUT I do need a seperate column (which will be empty after starting a sprint) to get any backlog items inside the backlog area to be displayed at all.
So wheter this first column stays empty or not - my point is: I do need this first column mapped to a status which represents the backlog items inside the backlog area. If I remove the mapping/the column, all 12 items shown in the first screenshot disapear instantly!
Why do you need the Backlog issues displayed in the Board view? What problem are you trying to address with that?
What you are asking for is contradictory to the design of the Scrum board in JIRA. For Scrum, the board is intended to display only issues in the Active Sprints. It has the Backlog screen for displaying issues in the backlog, displaying sprints that have not started, and for moving issues from the backlog to a sprint. There is no feature available to make the issues in the Backlog section of the Backlog screen display in a column on the Board View for a Scrum board.
There is not a Status that equates to issues in the Backlog section of the Backlog screen for a Scrum board in a Company Managed project. Issues in the Backlog can actually have any status that is valid for the project/issues. They will only display in the Board View when they are included in Active Sprints.
I'm not clear what you mean by
If I remove the mapping/the column, all 12 items shown in the first screenshot disapear instantly!
Can you walk us through the details of exactly what you are doing in JIRA for this and include before and after screen images?
Can you show use the Board Settings > Columns screen that shows the mapping of statuses to columns for your board?
Why do you need the Backlog issues displayed in the Board view?
You got me wrong Truddy - I don't want/need them displayed in the Board view. I thought they would be, but fortunately the were not. All I want is to get rid of the need, that backlog issues have to be mapped to the first column AND this first column is beeing displayed on the board.
A real walk through with screenshots would take too much time/effort. I will try to explain step by step what I'm trying to accomplish verbosely instead:
The Kanban Board works like this: Lets assume you've got 3 status values - TODO, DOING, DONE. You can map your Backlog to TODO. All items in your backlog will have the status TODO. By dragging them from your backlog list to "the board area" above the list, they will transition automatically to DOING. Your're dragging them literally from one (=first) column to another (=second) - not on the board view, but inside the backlog view (or as I called it: the "backlog ares"). Switching to the Board view, your first column will bei the DOING column, you will not have a TODO column in your board at all (thanks to the "Kanban backlog" feature, which allows you to "hide" the first=backlog column). That's exactely what I want the Scrum board to behave like - but Scrum handles things totaly different (it seems) =>
Lets do this again in Scrum with (almost) the same 3 status values PLANNING, DOING, DONE. You have to map the PLANNING column to your backlog as well. All items in your backlog will have the status PLANNING then. By dragging items from your backlog list to "the board area" above the list (=your active sprint) they will NOT transition anywhere - instead they keep the status PLANNING. Then you stop your Scrum planning and start/activate your sprint and switch to the Board view. Surprise, surprise - since the issues were not transitioned, they are still hanging in the first = PLANNING column... which makes me facepalm myself. I need to move alle issues from PLANNING to DOING myself... or... wait a minute... - idea! - why not let do this JIRA for me using JIRA automation upon a "sprint started" rule? Done! One problem solved - upon Sprint activation all issues move to DOING automaticaly now. Great. Still I'm getting hooked to a - now empty - PLANNING column, I can't get rid of. If I only could tell the Scrum board to hide the backlog column, the way I can do it with a Kanban board using the "Kanban backlog" feature...
That's the whole story. I don't think I can explain it in a better or more understandable way.
Taking a look at my original post I believe, I've got some things wrong there... especially the whole "As a result, all items listed in the "backlog area" of the Scrum board are getting displayed on the board itself as well" part. Thats very confusing and misleading :-( What I realy wanted to say is, that I don't understand, why I can hide the first column in Kanban but not in Scrum. And wheter there is a workaround to get rid of this first column beeing displayed in Scrum.
Sorry for the confusion.
Thank you for that explanation. I believe I now understand your dilemma.
With the Scrum process it is assumed that you will be adding many issues to your sprint and that work will not be started on all issues immediately when the sprint starts. Based on that logic, it is reasonable to have the issues in the PLANNING status when you start the sprint.
It is anticipated that you may include more issues than can actually be worked on simultaneously, and only the issues you are actively working on would transition to the DOING status.
As the work is completed on those issues, they transition to the DONE status. The engineers then select another issue from the PLANNING status in the current sprint and transition that issue to DOING.
In this flow, an active sprint may have issues in each status (PLANNING, DOING, DONE) and it is expected that the team would want to see on the Scrum board the issues included in the sprint for which work has not been started (PLANNING). Therefore you would have a column for each status on your board.
I did an experiment to try to understand your situation with your desire to have all the issues move to DOING when the sprint starts and not include the PLANNING column at all in your board.
I first set my scrum board to have the three columns with mapped statuses - PLANNING, DOING, and DONE. I created some new issues and confirmed they displayed in the Backlog section of the Backlog screen. Using Board Settings > Columns, I unmapped the PLANNING status from any columns. When I did that and returned to viewing the Backlog screen, the new issues I had previously created that were in the PLANNING status were no longer displayed in the Backlog section of the Backlog screen. That was completely unexpected to me. I did not realize that unmapping a status from the board columns would effectively hide the issues in the status from displaying in the Backlog screen also.
Now I fully understand what you experienced.
That was completely unexpected to me
Yeah... that's a crucial part of my problem :-(
Following your explanation of how the Scrum process might be handled, the way JIRA behaves makes sense. Thanks for this approach... I will take myself some time and rethink it tomorrow. Still it feels a little "odd" that you can have kind of "two backlogs" - the "real" backlog with the listed issues inside the "backlog area" AND some kind of a "working backlog" or "active sprint backlog" displayed as the first column on the board view.
Our "interpretation" of Scrum is (unfortunately?) a bit different. We belive, the entire "planning" part of Scrum should happen in the backlog (area) - not on the board. This includes the engineers drawing further issues into the active sprint. This approach is not well supported in JIRA :-( Having a way to hide the first=backlog column would solve the problem (in addition to some JIRA automation magic for the needed transitions ;-) ). And this feature even does already exist - but incomprehensibly only for Kanban boards :-(
For me and my team planning is done in Backlog. Planning equates to defining what the team commits to achieve in a sprint. Starting a sprint signifies the end of planning. When the sprint starts the team will begin working on issues in the to do status moving them to in progress and eventually done and pull the next to do issue.
@Jack: I see it exactely the same way, Jack - still there seems to be a little but important difference between your workflow and mine. Your workflow seems to be something similar to TODO - IN PROGRESS - DONE. Starting a sprint results in all issues beeing shown in the TODO column... and you don't bother about your planning step having the status TODO as well. In your workflow there is no differentiation between "planning" and "planning is finished - lets start to work". Thats perfectly fine for your approach.
My workflow is rather something like READY FOR PLANNING - READY FOR DEVELOPMENT - DONE. I have a differentiation between "planning" and "planning is finished - lets start to work". It's not just a matter of perspective - amongst others I need this differentiation, because I have an entire workflow mapped to a Kanban board right ahead of the Scrum workflow.... and the final workflow step on this "upstream" workflow ends with the status "READY FOR PLANNING"... which is perfectly fine for Scrum planning (as mentioned by you) but becomes "incorrect" once you finish planning and start a sprint (resulting in all items still beeing READY FOR PLANNING... which of course is not correct, since they should be READY FOR DEVELOPMENT after planning ends). The transition itself is not a big deal thanks to JIRA automation. But in the end I'm stuck with an additional (=first = READY PLANNING) column in the board view I don't need :-(
It's quite tricky. Small differences have a rather large impact. And of course there is no "right" or "wrong" - it's just two slightly different approaches.
Project managers know this problem: A “mountain of work” lays in front of you, and you don’t know how and where to tackle them. Different to-dos lie ahead, but just one task after the other can be ha...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events