Last week, at work, we were planning for a long-awaited team break. After much brainstorming and nailing the destination, there was a rough vision one could envisage. Now the team knew ‘what’ but ‘how’ still had to be figured. Numerous discussions and negotiations started around logistics, transport, food, etc.
During the dialogs, one of them started creating the checklist which was later revisited a few times and not to mention the re-prioritization of some entries. Yes, even in our day to day life we can witness many situations that can actually relate to the process we talk about during work hours. Here, the colleagues were planning for an outing that required a to-do list. In the same way, any product, event or mission requires step(s) of activities to be ticked off before it can be marked as done. In layman terms, this list can be referred to as the backlog.
Backlog = list of features, bugs, enhancements, technical debt and any item that is related to the product. In simple terms, if it does not exist in the backlog, it is not required. Contrary wise, even if it is in the backlog, it does not guarantee the delivery. The backlog candidates initially are imprecise, sometimes, in the form of placeholder items to avoid missing on the requirement in the later phase.
You might have experienced the scenarios where the team parks the discovered requirements to be detailed out once it is prioritized. Visualize the backlog as a pile consisting of items of diverse entities with different types and sizes. Each having their own priority and estimate. Remember, this pile is NOT locked, things can come up or go down as per the market need, some items might even get deleted, which is OK.
You may also like: The most common Scrum mistakes and How to avoid them
Consider creating a backlog for an online shopping portal – Shoppingmania.com (dummy name, not acquired till now). As a client, you want a section for grocery, apparel, accessories, and payments. Each section will further have their sub-headings. For example – grocery will have green vegetables, daily needs, kitchen supplies, personal care, etc.
You want your customer to get an awesome experience with their shopping. Hence, you might even want a fluid interface with minimal performance issues. You see, all these get into your pile of wishlist or the backlog.
The requirements in the backlog are not always precise and complete, they have to be made ready for consumption by the delivery teams. Once we have the pile, the team along with the business representative starts detailing and shaping up the requests. If the items are big enough to be completed in a sprint, the team breaks it down further for an easy feed. Estimation of the smaller chunks along with revisiting prioritization is done among the delivery team and the business people.
When Scrum was devised, Backlog Grooming was not prescribed as one of the ceremonies but Ken Schwaber advised the delivery teams to dedicate five percent of their capacity for this work. This activity is also sometimes known as ‘Story Time’ or ‘Backlog Refinement’ but whatever the name be, the intent is the same.
“Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly. It is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.” - Mountain goat
Backlog grooming is done by the development teams along with the product owner to ensure the backlog contains the fitting items which are estimated and ranked. Items towards the top of the pile should be ready for commitment and delivery as compared to the items on the bottom which are coarse and needs refinement.
Grooming the pile is important as this is the time when teams move out the user stories that no longer appear significant, with subsequent discussions the team might feel the need to create new user stories in response to newly discovered needs. Reconsidering the relative priority of stories and their estimates. Amending estimates in light of newly revealed data, splitting user stories which are a high priority but too bristly grained to fit in a forthcoming sprint.
Backlog grooming can be assumed as part of the entry criteria for the stories in the upcoming sprints. It not only gives the clarity on the work items but it also helps to identify and resolve the dependencies which might hinder the sprint work once it is committed.
A groomed backlog can increase the productivity of the team and helps them keep moving forward along the goal path, indirectly leveling up the team morale. While estimating, the teams can use estimation techniques to size the requirements. The widely used method – poker planning, comes in handy for almost all the teams. It not only initiates the discussion but also helps in exploring the hidden parts.
Backlog grooming helps the teams to learn from each other when an item is picked up for discussion. The team starts to brainstorm and focus on a single requirement on the table. This enhances the knowledge for all the team members, there might be a few scenarios which one has missed but during the dialogue, it got resurfaced. Some go with the technical discussions where complexity can be reduced through approach talk.
You may also like: Top 25 Scrum Master Interview Questions and Answers
If the teams miss on the grooming, the backlog might turn into a dumping place which is not sorted or visited. It might have stories which are no longer needed or the stories team created but forgot. Hence they end up having duplicate requirements with a cluttered pile. In such cases both, the team and the client, face the challenge.
Backlog grooming should be attended by the product owner or the business representative and the delivery team. There is no compulsion for all the team members to join the meeting. Ideally, the team should set aside some time during the planning of the sprint for the grooming activity. The product owner should always be there as they are the ones coming up with the client needs. The development team looks from the technical feasibility and ensures the requirement is doable. This is the meeting which helps both the parties – the product and the delivery team.
Grooming is where we deep dive into the requirements, it gives clarity and opens up the doors for better delivery. As goes the saying ‘precaution is better than cure’, it is critical to understand the technicalities upfront, discuss and resolve the dependencies (which might span across teams in some cases) rather than pulling it up unprepared and getting blocked. An effective backlog grooming makes way for smoother sprint planning.
You may also like: What's the Difference? Agile vs Scrum vs Waterfall vs Kanban
The team decides when and how to plan for the grooming session, there is relatively small direction from the Scrum Guide on the cadence. The teams usually plan the backlog grooming prior to the sprint start. But in the case of Sprint Planning, there is a set rule – It has to happen as the first thing at the start of the sprint and has a set pattern to follow. The Scrum guide states that Sprint Planning should be divided into two parts -
What is to be achieved in a sprints’ time and
Planning on how to get it done.
Backlog grooming helps the teams to make the requirements in ‘Ready’ status. Hence in the sprint planning, the teams can focus on detailed interpretation, sculpting the approach and re-estimation. Pre-work on the backlog helps to make the sprint planning precise and effective.
Backlog grooming is an ongoing activity to refine the pile of requirements. Sprint planning focuses on committing for the sprint goal. Grooming helps in setting up the ‘Definition of Ready’ for the stories.
You may also like: Scrum Hacks: How to work with distributed teams
Most of the time, the team complains about attending a lot of meetings or long meetings which hampers their output. It is important to understand the value add of backlog grooming – if done with the true spirit. Scrum Masters can help the teams realize the significance and adopt it as part of the process. Though it is not a prescribed meeting but has immense value.
In one of the conferences, I met with this Change Agent who was struggling with low productivity. Even though the teams were working hard, they reached a point where the culprit was identified as Scrum. Really? With further discussion, missing the backlog grooming was acknowledged as one of the reasons because the major hurdle was the frequent impediments due to non-clarity of requirements and unidentified dependencies. Personally, I am not a very big fan of meetings but this one is something which I think none of the teams should skip.