The concept of a backlog is pretty basic. We need some means to capture all the request we receive from all our stakeholders. At my home, I have many stakeholders. The main one is my wife. She shares many things that need to do. So I add them to my backlog of tasks. Similar to some stakeholders at work she would like them all done now. It reminds me of a customer that I worked with when we asked him which one was the priority. He exclaimed, “they all are!” We must come to grips with limited resources and time.
What is a backlog?
According to our Scrum.org, “the Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.” So we should start with a list of the requests and then put them in order. This can be challenging when you have multiple stakeholders. Someone is not going to be happy.
What is backlog grooming?
Before I started in learning much about agile I remember someone saying it is “programming with more meetings.” I wasn’t sure whether that was a good thing or a bad thing. It seemed that they didn’t care for it though. One of those meetings is a backlog grooming session. According to the Agile Alliance, “Backlog grooming is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.” One of the key words in that description is “appropriate items”. I have seen many product backlogs with someone’s pet project that shouldn’t be there.
Who should attend?
Some people enjoy coming to meetings. They usually are the more social ones. It seems more like a party to them than work. I am all for people enjoying their work. When it begins to waste time though, I draw the line. A backlog grooming meeting is a place where you only want key people. As Mike Cohn points out here, we need to be careful who we include. Depending on where you are in the current sprint some team members might not be able to attend. Also be careful of people who may not be on the team but try to influence the outcome of the sprint.
Does everything go here?
When I first became a scrum master I made the mistake of letting every stakeholder add things to the backlog. I had no litmus test about what was on there. This led some people to ask when their item would be worked on. As we went along we developed some criteria about what would make the backlog and what would not. We need to develop a series of gates to control things coming in. Working with the stakeholders and product owner we developed some steps. This helped eliminate everything crowding out some of the important requests.
Being a product owner is a tricky role that requires you to balance many priorities from different stakeholders. Everyone has input on priority and which items should be on the product backlog. Meeting with the stakeholders at regular intervals can help. If you have problems with this it can be helpful to have people review the backlog board. I found this to be helpful with some stakeholders to remind them of all the items they are asking for.
Backlog power struggle
Determining the priorities can lead to a power struggle on the backlog. Stakeholders can try and jockey for position as the person in charge. The Product Owner needs to assert control here. They need to show that they have the authority and sometimes make people mad. That is going to happen. Of course, people can get mad about this but we have to move on and make decisions. We have to remind people that we like the Rolling Stones song, “can’t always get what we want.” There needs to be a give and take on priorities.
When should we groom?
I have heard a lot of opinions on when we should groom our product backlog. I have to say I have tried a few different ways too. Roman Pichler shares some good points in his post here. He gives us four good options. First in the sprint review meeting. Second is prior to the sprint planning meeting. Third after sprint planning meeting or fourth continuously. I have mainly worked with the first two options but I would like to try the last two and see what results we get.
So as you look at your product backlog you may have encountered some of these issues. Try some of these suggestions out and let us know how it works. Agile development embraces the inspect and adapt mindset. It is more a mindset than a set of explicit steps. As you groom your backlog keep improving your process along with the other aspects of your development system.