Both the terms "Sprint Backlog" and "Product Backlog" can be used interchangeably because generally teams follow Scrum methodology for product development and in Scrum you have work based on Sprints thus the Sprint Backlog is can also be called Product Backlog but vice-versa is not always true. As Product Backlog can be for next 3 months but only few features from that backlog will make it into the Current Sprint and some other top requested features of the product backlog which are highest in priority can be called Sprint Backlog as they will be worked upon in next Sprint.
In JIRA there is just "Backlog" term and as I have explained above the Backlog items are used as Product backlog / Sprint Backlog.
Agree with Tarun, but let's take it a bit further...
Assuming you have groomed the "Backlog" view in JIRA and assigned 10 issues to the current sprint. Now as you look at the Sprint view of the board, some issues are being worked on some are waiting to be worked on (i.e. To Do). I assume you are referring to those issues not yet being worked on as "Sprint Backlog". So... for most of us, the Sprint Backlog is the 1st column of the sprint board where we see issues that are part of the Sprint but not yet started. Hope this helps, ask some more questions if you need further help.
Thanks guys for your response.
And you are right in terms of the To Do column. That can be renamed as 'Sprint backlog'. However it would be useful if you could have a distinct backlog that is the 'Sprint backlog'. I say this as you can have items in a Sprint backlog that could cover 1,2,3 or 4 sprints.
But I think a renaming of that column is the best bet.
"you can have items in a Sprint backlog that could cover 1,2,3 or 4 sprints."
Well, according to theory (which by the way never keeps me from doing what works) you should not have stories/issues that go across sprints. (EPICs - yes, of course) If you have a lot of that happening, you might want to consider breaking things into smaller work items and/or consider that you are over committing the amount of work that can be done in a Sprint.
You might also consider adding swim lanes to sort things out. For example we have one for EPICs for the very reason that they tend to cross multiple sprints. We normally don't want to see them on a day-to-day basis so using a swim lane allows us to contract them.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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