For my project I have 3 boards a kanban board each for analysis and testing and a scrum board for development. I have status's that are mapped to the analysis and testing boards and not mapped to the development board. This means however that when looking at the backlog view the tickets that do not have status's mapped to the development board do not show up in the backlog view. Any ideas how to make it so I can see all tickets in the backlog without having them mapped to the development board.
Nic Brough: "You can't. You're effectively asking to see issues you have chosen not to see. It's one or the other.
If you want to see an issue on the board, it needs to be selected by the board to be visible - the board filter needs to select it and it needs to be told in what column to appear."
No. I'll go out on a short limb, and say it. You are incorrect. You're trying to "fit" Scrum to the limitations of Jira. This is NOT "how a Backlog" in Scrum "works".
Any WORK, is the backlog (things that are or might become "Product"). Whether
A board, to visualize the work...is NOT the backlog.
What the OP is trying to compartmentalize is:
As a Customer
I want to see
Jira Backlog Screen -> Display (2) and (3)
Jira Active Sprint Screen -> Display (2) and (1)
So I can...DO MY WORK.
This IS how Scrum differentiates Backlog (the work) from Board (a particular visualization I've decided might be useful for display the flow of the work). Not because I'm both a Scrum and Kanban trainer (because I am), and not because I say so, because that's what the Scrum Guide says (and speaking as the original translator of the Guide into Spanish, I think I'm pretty familiar with what it says).
Jira has this woefully broken. I hope others find this, and upvote this to the sky, because the day Atlassian FIXES this, it will actually have accomplished something very useful to A LOT of people.
The way you have written this suggests that you have not even looked at a Scrum board in Jira software.
If you had, you would see that a Scrum board has two views you switch between
So Jira already does almost everything you describe, exactly as you say in your "As a customer I want to see" bit. Your essay barely has any reference to the original poster's question or my response.
You have also got the definition of backlog wrong. You say "Any WORK, is the backlog (things that are or might become "Product").". This is broadly correct. But you then say "it includes done items". This is absolutely wrong as "Backlog is simply a list of all things that needs to be done within the project." - in other words, a backlog does not contain done issues, because they do not need to be done, because they already are.
"A backlog, which lists all issues selected by the board filter except those that are complete. This includes issues allocated to sprints - the sprints are boxed out at the top of the list."
-- this used to be true. Now, even if I have the backlog status included in the filter, if I do not have it mapped to a board column, it will not show on the backlog view. Even if items in the backlog status will never show on the board (because I will never assign them to the active sprint), I still have to actually /map/ it to a board column in order for it to be visible under the created sprints, which seems bizarre to me. But as I've said, I am pretty sure it used to work exactly as you describe, and paid attention to the filter only rather than the mapping.
Just having this issue myself, I'm surprised at the divisiveness in this thread as it seems straight forward to me, and agree with the original poster; the backlog should be based purely on the filter for the board, not on whether statuses are shown on the board columns or not.
I have multiple board views for different roles, so devs for example don't need to worry about all the steps done before a ticket is ready for development (ie design/discovery sprints) or statuses for the steps the testing team need to do once development is complete.
I'd still want to see all backlog tickets irrespective of which board I'm viewing. I've had to create one board to rule them all which incorporates all statuses, JUST so I can see the full backlog, then I have to switch to my PO board or whatever to see the statuses and columns I want to see on the actual sprint. Sprints and backlogs should be separate, and the backlog should show all backlog tickets irrespective of the statuses I have in my columns on the sprint board.
Yes, that's right, a board shows you everything that a filter selects for.
The thing that is a problem here is that you can leave status out of a board mapping. It's not wrong in itself, a lot of us have uses for boards that ignore issues in certain status.
What you are not understanding is that choosing to ignore a status in a board means, well, you don't see it on the board. You have chosen to ignore that status.
Which is it? Do you want to see all the issues irrespective of status, or do you want to ignore some. The backlog and the board are different views of the same list. It's not right to have them give you different lists.
It such a long time for something that should be simple.
I also added some statuses that is not part of the development to help me with the backlog grooming and handle the refinements, thus logins the ability to see the full backlog in the main SCRUM board > backlog
@Nic Brough were you able to solve it?
I have this same problem. In my mind, the Backlog should not be governed by which columns are visible in the Board. To me, the Active Sprint should use those board settings, but the Backlog is separate of that. I want to be able to click Backlog, scroll down to see the items in my backlog, and be able to use and see the "pre-work" statuses that I have defined in the workflow (i.e., To Estimate, Estimated, Needs Design, etc..).
This is a pretty basic workflow for project managers trying to groom upcoming sprints.
I'm now trying to create a separate Board for Grooming, and it's like pulling TEETH to get my tickets to show even there. I now can't see any tickets I've put in Estimated & To Estimate, even though I've mapped those statuses to columns in the new board, and Jira "knows" in the counts shown when mapping statuses to columns that there are tickets there. ARRRRRRGHHHHH!!!! *shakes fists at Jira*
>I have this same problem. In my mind, the Backlog should not be governed by which columns are visible in the Board.
Why? The backlog is a feed-in to the board. If you're going to have issues that won't be on the board, then you don't need them in the backlog either.
You just need to map your columns to show the issues that you're going to be actually working with, then your backlog will contain all the issues you're going to be working with.
You can do it in Jira - set up the board to cover what you need to refine and work on. That's the whole point of the board - it shows you everything you are interested in.
You say "when grooming the sprint there are statuses that don't apply to the work in progress in the currently-being-worked sprint." - that is not what a board is for and it is not how scrum works. Grooming (refinement) is done in the backlog to get things into a state where they can be drawn into a sprint. Once you've started a sprint, you would look at the active sprint board to update issues in the sprint, not the backlog. Either way though, you are not interested in items that are not on the board, they're irrelevant to what your team is working on, by definition.
All you have to do here is add your (currently non-sprintable because of their status) items into the backlog, by telling the board that that status is sprintable. Just add it to the to-do column (in most cases)
> You say "when grooming the sprint there are statuses that don't apply to the work in progress in the currently-being-worked sprint." - that is not what a board is for and it is not how scrum works. Grooming (refinement) is done in the backlog to get things into a state where they can be drawn into a sprint.
Exactly. Grooming is done in the backlog, but the act of grooming tickets follows a different workflow (statuses) than the tickets that have been prepared (groomed) for work in the Sprint.
> Once you've started a sprint, you would look at the active sprint board to update issues in the sprint, not the backlog.
Of course. We do look at the active sprint board to update the tickets in the sprint. But that's not what I (or the others in this thread) are talking about. Again, we need to use statuses that *do not apply* to the tickets in an active sprint. I'm talking about the significant amount of work that happens BEFORE this stage.
> Either way though, you are not interested in items that are not on the board, they're irrelevant to what your team is working on, by definition.
But we ARE interested in the items that are not on the Active Sprint Board. It's very relevant to what PART of our team is working on. We have to groom those tickets. There is "pre-work" that must be done on incoming tickets from our clients to groom them. That work is done by me and the lead developer, not the whole development team. It includes (as I have said above) statuses that do not apply to the developers doing the current work in the current Sprint. I create a ticket, in the backlog, and write the description based on the requirements. Then the senior developer needs to access those tickets, add any technical instructions needed, and add an estimate. I want to have a status called "To Estimate" for those, so he knows at a glance which ones are ready for him to do his part. Then when he has estimated them, I want him to change the status to "Estimated" so we both know the estimate and tech instructions are there without having to open the ticket up. If a ticket is waiting for design from the client, I want a status that says "Waiting for Design". None of these statuses apply to the developers doing the current sprint work, and we do not want all those statuses to clutter up the view of the development team on the current sprint, using the Active Sprint Board.
>All you have to do here is add your (currently non-sprintable because of their status) items into the backlog, by telling the board that that status is sprintable. Just add it to the to-do column (in most cases)
We do not want tickets in the grooming stage to appear in the To Do column of the Active Sprint Board. The tickets that are there should be tickets that are in the current sprint, groomed and scheduled and ready to work, but have not yet been started. The problem that the people in this thread are describing is that the backlog is governed by the statuses that apply to "sprintable" stage. We have no way to track the different statuses of the "grooming" stage.
(However, I did try to make a separate Board for this grooming work... I think that would work for what we want to do, but the tickets are not mapping to the columns I have created in that board. When I go to the column settings on that new board, and map my "grooming" statuses to matching columns, Jira knows that there are 8 tickets in Estimated status on that settings screen, but when I view the board itself, those 8 tickets are not visible. Still trying to get that to work...)
Ok, so what you're saying is that you have a process which you are mistaking for "grooming" in Scrum. There's a whole cycle of work your refinement which is not what scrum does.
You're then confusing things by trying to wedge this process into your scrum as though it is a an item that you're not going to sprint with, and then eventually might. But the boards (and their backlogs) are built for handling a single process for a team, not items that are not included.
You're setting up "Schrodinger issues" - they're both sprintable and not, and then you're expecting a tool built for handling sprintable items to handle them. It simply can't. You need to decide whether you want an item to be sprintable or not and handle the two types differently.
You need to separate out the two processes (grooming and the actual scrum) and then you'll be able to set up boards to be able to do each one. They can't be on the same board, you've explicitly decided to handle items.
> You're setting up "Schrodinger issues" - they're both sprintable and not, and then you're expecting a tool built for handling sprintable items to handle them. It simply can't. You need to decide whether you want an item to be sprintable or not and handle the two types differently.
You are talking gibberish to me. Every single one of the tickets we add to the backlog are expected to be scheduled into a sprint. They're all sprintable, they are simply "pre-sprint". No cat here. Just two separate processes (stages) of work that are needed on the same set of items (tickets), performed by different people. Two stages, one set of items. All sprintable.
We can agree on this: while what I and many, many people in the world refer to as "grooming" is a separate process from "sprinting", so what I/we need to make this work in Jira is a separate board to manage that separate process, whatever it may be called - I don't give a flying flip what that is - the work still has to be done no matter what we call it. Doesn't matter one bit to me if it fits the definition of scrum. All I want to do (same as others on this thread) is manage a process on a common set of tickets that is working just fine for us, using the same software we use to manage in active sprints.
However, in trying creating that separate board, there is either a bug that is causing that not to be a viable solution for me, or I'm doing something wrong. See my last paragraph of my previous post.
>Every single one of the tickets we add to the backlog are expected to be scheduled into a sprint. They're all sprintable, they are simply "pre-sprint". No cat here. Just two separate processes (stages) of work that are needed on the same set of items (tickets), performed by different people. Two stages, one set of items. All sprintable.
No, that's the whole point. You are not doing this.
"pre-sprint" means "not sprintable (yet)", you can't have it both ways.
Your grooming process is not a bad thing to do, but it happens while issues are not sprintable. It's not part of the sprint process, so you have (rightly) removed the status from the board, but that takes your issue out of the backlog refinement process because the items in those status are, by definition not part of it.
>many people in the world refer to as "grooming" is a separate process from "sprinting"
Yes, absolutely, that's correct. But grooming is preparing items to a point where the team has enough information on them to be able to choose to take them into a sprint. For that, you should be looking at all issues in any status, and they should be sprintable - so you should be including them in the board. If you decide that grooming is not to be done as part of the team's normal work, or even should be done by a different team, that's fine, but you need to understand that it is not refining sprint items, it's "information gathering to inform sprint refinement".
So, I would try to represent your processes accurately, with separate approaches and boards to work with these processes.
Imagine a workflow that is broadly
New -> in pre-refinement -> ready for dev -> in dev -> done
Your development team, using the sprint board, they don't care about status new and in pre-refinement, so you set up their board with to-do = ready for dev, in progress = in dev and done = done. They probably have very little refinement left to do, but their backlog will be entirely made up of sprintable items.
Then for the people doing the pre-refinement, you define a second board, probably with the same filter, but their board should only include new, in pre-refinement and ready-for dev (you could leave in-dev and done in the done column with ready-for-dev on that board too). I'd probably use a Kanban for that, as your refinement process probably isn't going to be a sprint process and it could look confusing. A kanban would just let it all flow.
In the case you're describing...
"New -> in pre-refinement -> ready for dev -> in dev -> done"
Technically speaking...all the items in BOLD, effectively map to "Product Backlog".
One can choose to create a "board" that maps to items in that those states as "Product Backlog", and then a "board" that maps to the remaining states as a "Sprint Backlog".
But as I said earlier....OOTB
Backlog -> To Do -> In Progress -> Done
is what causes folks most of the "head jarring" because they have to move "Backlog" into a column in the Kanban (don't call it a Scrum board, please), to be able to create and view items that are in the Product Backlog.
As is already defined in the Kanban Template, if one selects the "Kanban Backlog" option, it works properly. This, should be the default behavior for the Scrum template.
If this were the case....a Team could then create "Sprints" labelling them accordingly to what's "In Refinement" and "Ready for Dev", which then precludes (for simpler Product Backlogs) the needs for multiple board views.
Terrific, thanks Nick and Marcelo. I get what you're saying about sprintable vs. not sprintable - makes sense. I will try making a Kanban board instead of a separate Scrum board (which is what I tried but couldn't get to work) for our Product Backlog as you suggest. Sounds like this is exactly what we need to do.
One thing I have not said yet that I really should do - I really do not feel this is in the slightest bit intuitive in Jira.
Nowhere do I see it explained in the UI that "unmapped status do things you don't expect" and the docs are very light on it, you have to read way too much to find it. If you do find it, you'll see it's technical and doesn't explain why it's this way at all, nor that the board and the backlog are actually (very different representations of part of) the same thing.
And to follow up on multiple scrum and kanban boards - that works really well, even with many kanbans added in for different custom views of anything.
My approach was:
Kanban board with JQL swimlanes per sprint
I do need to update the JQL here and there but I can have all tickets per status + without sprint in the bottom;
Still, I would like (as you started saying) love to see this also available in the SCRUM board but still prefer this to an excel/sheets file
I encountered the same issue today and found this thread. Though the thread did not give any solution, but it confirmed that it is an existing behaviour (i.e.) unless you map the status on the board, you cannot see those issues on Backlog.
I used a work around to address this issue. Created a new filter on the Active Sprints board using JQL to exclude all the issues with status' that I don't want to see on "Active Sprints" board. But mapped those status on the Broad settings to one of the existing column (e.g. Sprint To-Do). That way I can see those issues in "Backlog" board but at the same time it is not visible on "Active Sprints" if filter applied.
I understand that is how it currently works in Jira. I believe the point myself and others are making is that this isn’t what many expect. Do users consider items listed under “Backlog” as ready to go across the board? Maybe there should be a board configuration option to “show unmapped statuses in backlog?”.
To expand upon that idea, the user would go into the board configuration and place select specific unmapped statuses into a “include unmapped status in Backlog” box. This way the user can choose which statuses are included/excluded in the Backloglist. Again, It should then be made clear that including any of these unmapped status issues into a sprint would automatically update the status of the issue.
My proposed solutions are simply to satisfy the expectations of more users to make for a better UX and help make the product more flexible.
Yeah i think it would be easy. But as you can see nic just repeats it over on over again. It's just not how they want it to be. Sad to hear the same answer over and over. Very dissatisfied with this community Forum the way we are treated. It's how it is. I won't post anymore here.
The reason I give a similar answer repeatedly is because people are not understanding what I've written before and I'm trying to explain it differently.
Please don't abandon the community just because you don't like or understand a particular answer.
I am very new to scrum.
Still this is a feature I need. It's just weird it doesn't work. I don't want a column for backlog in my Sprint. It distracts from working.
I want to see only the Sprint stuff in the columns not the backlog. But if I don't map it to a column it's not there. That's really weird.
Should be a easy fix
I understand your point. I understand that in JIRA the board is a view and not a container. That's the infrastructure behind JIRA.
I as a customer would like to have an extra feature. Let's not call it the board then. I want to be able to have the backlog where I can plan the sprints. I want this apart from the board. I want the board with the colums NOT to show the backlog. It just creates stress in the peoples heads that want to just do their stuff. They get stressed. Its mental not IT.
If it doesnt work in JIRA okay fine. If they cant do it fine. But the wish to have it is still very reasonable and okay.
This is how scrum works. Scrum board doesn't have a backlog in a sprint because in a sprint you are working in those issues. The backlog in scrum is the list of tasks outside a sprint and, when a task is in a screen, it is not in the backlog anymore.
Anyway, you can see the issues in the "backlog" menu but above the "backlog" and it is called sprint.
I think I'm not explaining myself clearly so hopefully the below example will make sense.
I have a staus called BA To Do, this status is currently only mapped to the analysis board. If there is no sprint tagged in a ticket with this status and I go onto the backlog view in jira this ticket does not show in the backlog. If I map this status to a column within the development board it does show in the backlog. I would like to know how I can have this status un-mapped to a column but still show tickets in this status in the backlog view.
You can't. You're effectively asking to see issues you have chosen not to see. It's one or the other.
If you want to see an issue on the board, it needs to be selected by the board to be visible - the board filter needs to select it and it needs to be told in what column to appear.
This answer doesn't make sense to me...
The backlog should display all issues in all statuses.
The active sprint should display all issues sorted into the columns I've created and the statuses I've mapped to each status.
In my workflow, I have a status called "Awaiting Review". This is the first step in the workflow before it's transitioned to "Ready for Development". I don't need the issues in the "Awaiting Review" status to be visible in the Active Sprint board because those issues are not ready for the developer to work on, but I do need them present in the backlog.
How am I supposed to groom my backlog if there are some statuses that don't appear here...?
You are not asking for a backlog, but for a report. A backlog is all the work that you haven't even started. When you have started to work on an issue, then it is in your board and it dissapears when the work is done.
Make a Dashboard or a filter which displays the issues as you need.
Disappointing to see this is still not resolved.
I understand how the board/backlog function has been implemented, but I do disagree with it. A board is based on a filter. The current implementation has the board columns act as an additional filter. So two filters that are added together to determine what issues are accessible are that are displayed in both the board and the backlog.
I believe there should only be the single filter that determines what issues the board has access to. Then the board and the backlog screen should let you modify how you want to view the result of that filter independently to each other.
I'm not sure what you mean by "not resolved". The problem is people not understanding what a board is for and how they are configured, which has been explained.
The only technical "resolution" I can see for this would be to remove the flexibility to not map status into columns. You'd get "one single filter that determines what issues the board has access to" and "you can modify how you want to view the result", alongside no-one being able to lose issues because they're unmapped. On the down-side, this would also stop people setting up boards that cover part of a workflow, which is useful for when issues move between teams.
I am new to Jira and ran into this same “issue” today. In my project, new issues are created with status=“Backlog”. My scrum board has “To do”, “In progress” and “Done” columns mapped to the statuses of the same names. Since status=“Backlog” issues are not mapped to my scrum board columns, those issues do not show up in my scrum board nor my scrum backlog.
I propose the scrum Backlog page/list should show all issues, regardless of status, that are not currently in a sprint and not completed(?). I initially expected to see my status=“Backlog” issues included. Assuming they are displayed, the question becomes how should they then be presented on my scrum board? I suggest that the an unmapped issue status should be changed to the status mapped in the left-most column on the scrum sprint board. Isn’t that essentially what I would be doing by specifically moving a Backlog issue of any status from the scrum Backlog to a sprint?
if there is already a way to do this, please let me know.
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