Product & Sprint Backlog Management with JIRA
How to manage the two important artifacts of the Scrum? The question is generally faced by almost every Scrum Master . What are the tools available to manage The Product Backlog and The Sprint Backlog.
Lets first refresh the definitions of both, so according to scrum guide,
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team
where as
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
Now back to the first question again, how to manage the two, should it be Trello Board, Miro, Jira or any online tool. This is not easy. You know what I mean when you land into waters.
Misusing & Mistaking JIRA ‘backlog’
Teams usually start with the JIRA Scrum project and often mistakenly use the ‘backlog’ as their Product Backlog and create a Sprint to manage their Sprint Backlog. This shall land the team into a quagmire of issues with no proper Product Backlog workflow, management and prioritization. To over come this problem, we at YolBe came with this solution and have been successfully managing both Product Backlog and Sprint Backlog ever since.
So here is what you would do.
Creating and Managing Product Backlog (Kanban Project)
Start by creating a Kanban Project , this will be your Product Backlog,
You can create your own workflow, for example this could be a simple workflow to start with:
Now this project is owned by the Product Owner, business and marketing team and Development Team actively participate to make sure that every feature/story is dev ready in all respects e.g. Complete definition of problem, Description of the features, Business Goals, Acceptance Criteria, associated Design Artifacts and associated Timelines etc.
Once an item reaches into the Dev Ready column, now it is ready to move to the Sprint Backlog Project, off-course based on its priority. This is done at Sprint Planning. Let’s now see how the Sprint Backlog is created.
Creating and Managing Sprint Backlog (Scrum Project)
Now, create a new project and select Scrum template for this. Create your own workflow, here is an example of a simple workflow and start by creating your current Sprint.
Process flow between Product Backlog and Sprint Backlog
At a Sprint Planning session, the team can now review the Dev Ready items in the Product Backlog(PB) and easily move them to the Sprint Backlog(SB) project or directly into the current Sprint.
Select the feature/story you want to move to the Sprint Backlog, Now clone it, you can now move the cloned story to the Sprint Backlog Project.
This involves few simple steps. Select the cloned story and from the actions drop down, you can click on Move to start the migration.
Migrating from PB to SB Projects
Step 1.
Step 2.
Step 3.
Step 4.
Step 5.
Congrats
Story is now in your Sprint Backlog Project, Now the story is ready to be moved into the current Sprint or any future sprint you have already created.
From here on, the story is owned by the Development Team and it can further be broken down into multiple User Stories, or Tasks/Subtasks depending on your own best practices.
At the end of the Sprint, at Sprint Review, and once the Definition of Done is met, the story can now be moved to Done in Product Backlog and the process continues at the next Sprint Planning session.
Happy Scrum with JIRA.
