All You Need to Know About Backlog Grooming
Before we dive into the backlog grooming ceremony, let’s take a step back to define the backlog which exists in every product. Simply put, it’s a list of features and functionalities that your product needs in order to achieve its vision. Those features pile up over time as the number of users consuming your product grows. It’s therefore a “living” list that needs to be continuously managed to prevent it from blowing up.
Backlog Grooming
Backlog grooming (or refinement) is the process of going through the backlog items and maintaining the list of new features, bug fixes, and enhancements. More specifically it includes:
- Clarification on what will be worked on next
- Ensuring high priority items contain all specifications and requirements needed
- Creation of new stories reflecting new needs
- Re-assessing priorities
- Editing/strengthening existing stories
- Story estimation determining effort and time
- Creation of sub-tasks
- Removal of unnecessary items
Attendees
Backlog grooming is best done as a SCRUM team meeting. There should be a good mix of development leads, engineers, quality assurance and the product owner. The PO should always be present in the backlog grooming; after all, they have the final word on the direction of the product. Having presence from engineers both frontend and backend is critical since they provide the technical insights that are necessary to strengthen issues to be prioritized.
Frequency
Typically it’s held near the end of one sprint to ensure the backlog is ready for the upcoming one. However, a good Product Owner does not wait for the grooming meeting to arrive but constantly grooms the product backlog to ensure it is up to date and make the life of their team easier. After all they are the best people to know what is still relevant when it comes to the direction of the product.
Duration
1.5 hours should be enough to groom the backlog. You might need 3 hours total in case you are running in 4 weeks sprint cycles. Make sure to establish the openness with your team to stop a discussion that is going down the endless road or is drifting away from the actual focus point.
Facilitation
The backlog grooming meeting can be facilitated by the Scrum Master as the PO together with the team are active participants in the meeting. In case the Scrum Master role is not present or the team has reached a certain maturity level, the PO can also steer the direction of this meeting with the help of a development lead or team member.
Importance
The backlog grooming meeting should be perceived as a sacred meeting since it ensures you keep your stories up to date, clear duplicates, spot missing requirements, clarify questions in time, get ready for next sprints. It is helping you increase efficiency by avoiding unnecessary discussions or wasting time in meetings when instead you could focus on building something.
An un-groomed backlog can cause frustration amongst the team members
Backlog Grooming Practices That Work
1. Size of the backlog
Lengthier is not necessarily better. Don’t be afraid of a backlog that is small in size. It probably means you are doing a good job with working on the most important topics and keeping your focus levels high. It also means that if you let it grow, items will naturally never see the light of day. So why postpone closing an issue now instead of months later?
2. Update statuses and leave comments
JIRA is a powerful tool if you use it in the right way. Making sure that the statuses are always updated and a comment to reflect status quo is present is helping anyone and most importantly your team to be efficient. They will be able to continue where someone else left things off and avoid investing time in something that you already know the answer to.
3. Write clear summaries
A good summary helps you a lot to remember what the issue is about when you are in the backlog view so you don’t have to always view the issues one by one. It also helps you quickly scan and check if you actually created this story that you were discussing yesterday or if it is still a to-do.
4. Write concrete tickets
It is important that you include a user story regardless of who your user is, define clear acceptance criteria, attach respective designs, specify potential translations as well as necessary tracking etc. All this helps you in smoother product development, increasing efficiency and being able to a couple of months down the road track what you have worked/tested already and what the outcome was.
5. Epics are not labels
Epics are a concept that has been used in all the wrong ways. An epic is a large body of work that can be broken down into a number of smaller stories and can be delivered in more than 1 sprint. They are certainly not to be used as colorful labels for organizing the backlog and introducing a new filtering mechanism.
6. Challenge estimations with comparable reference stories
If you wish to get better in estimating the development work needed on your product, a good way to do it is to have 2–3 reference stories that have high, medium and low estimation assigned to them. When you then assign estimation on a new story and you are in doubt, quickly reflect whether it is more complicated than one of your reference stories.
7. Estimate ALL issues
Whether we are talking about bugs, quick tasks, stories or spikes, it is vital that you put an estimation to it, because if you don’t, you might end up spending half of your sprint investigating or trying to solve a bug. You are not in a position to show what you worked on in your reports later on simply because you did not assign an estimation. So what did you work on?!
8. Plan some sprints ahead
Instead of having your current, running sprint and the entire backlog under it, create some sprints with a potential objective. The objectives can derive from your quarterly roadmap plan. This way you can start allocating some early tickets to those sprints and approximately assess whether you are committing to more deliverables that your team can handle.
9. “I will create a ticket“
There is always the tendency when someones approaches POs with an idea or the team with an improvement to say “I will create a ticket.” This gives the stakeholder the fake perception that it will get done at some point soon and you the happiness of buying some time. Don’t do this because you will fail in meeting their expectations and then there will be even higher frustration than if you were honest from the start. Prefer instead to think whether this is something likely to be done soon and provide direct feedback and reasoning which can simply be “It is not part of our direction the next couple of months” or explain why you do not believe it should be pursued.
10. Don‘t be afraid to close issues
Your backlog is not a “nice to have one day” list. If you have postponed prioritizing a ticket for some time now and it is there for more than 6 months, you have good reason to believe that it will remain there for another year. So why don’t you close it today and save yourself the time from going through this pain some months later?
