The team was under pressure to deliver a rewrite of the flagship product after having been handed an agressive delivery date. In spite of the Scrum board and other information radiators in their area, the Scrum Master had to deliver progress reports to the CEO every day. The company president and vice presidents attended sprint reviews and grilled the team whenever a story was not closed or sprint goal not met.
One could easily argue that a fixed scope and fixed delivery date is in no way agile – end of discussion – but this still happens in organizations that use (at least partially) agile practices leaving Scrum Masters to navigate choppy waters.
Of course the team developed some coping mechanisms, the most insidious of which was kicking the can down the road.
Whenever the team encountered unexpected complexity or scenarios when working on a story, they said “this wasn’t in the story that we planned, so let’s call the current story done so that our sprint metrics will look good and handle the extra stuff sometime later.” Everyone except for the Scrum Master was happy – for awhile. Team velocities looked good. Stories were being closed as planned. On the surface it looked like features were being completed. The teams were going to deliver on schedule. The Scrum Master knew deep down that they were either going to deliver late or deliver an application with enormous amounts of technical debt. She also knew that the organization could not handle to truth so she soldiered on.
Then the bubble burst. The collective “oh crap” moment happened when people realized that the system should be production-ready but was not. Some features were incomplete. Bugs were still there from parallel testing that had been performed months ago. There was no room in the time before the expected completion date to resolve all of the open issues. Market launch would be delayed.
The ‘shadow backlog’ existed in the developers’ minds and in the list of open defects that were logged elsewhere from ongoing user testing. There were no product backlog items for them and no sprints in the release plan for addressing them.
– Make sure that all remaining work is visible. Create backlog items for stories, technical debt, and bugs. The backlog consists of Product Backlog Items (PBIs), not just user stories.
– Get user feedback during the sprint to avoid surprises later. Ideally users are integrated into the process via acceptance test driven development (ATDD). At a minimum they have an opportunity to see stories in action and provide feedback in the sprint. Any feedback and new ideas that cannot be incorporated during the sprint should be captured as real backlog items and sized/prioritized.
– Don’t be afraid to keep a story open if it was more difficult or took longer than expected when sprint planning was originally done. Better to take a little heat now rather than have the bubble burst later.
– Avoid ‘bucket stories’ near the end of a release that become a dumping ground for stuff that did not get completed in the sprints. Bucket stories can quickly grow exponentially and delay the release.
As a Product Owner, I start each day by asking myself, “How can I best serve the team today?” The PO and Scrum Master’s roles as servant leaders is not news. The challenge for the PO is translating this mindset into actions. It is all about mastering the cadence of product ownership.
Assuming that a backlog is in place and the team is working on the user stories, the Product Owner’s typical activities are something like:
- Attend daily standups. Every day.
- Help the Scrum Master resolve certain blocking issues for the current sprint.
- Meet with team members to answer questions about stories in the current sprint.
- Prepare for the next backlog grooming meeting. Revisit backlog prioritization, identify which stories will be groomed, add Acceptance Tests/Criteria or other information to the stories. Consult with end users or business stakeholders where appropriate.
- Facilitate backlog grooming meetings with the team.
- Receive demos of or perform testing for stories as they are completed as part of the sprint. This is typically part of the team’s Definition of Done.
- Meet with clients/stakeholders/users to discuss and define future product plans.
- Participate in the team retrospective.
- Facilitate the sprint demo.
- Prepare for the next sprint planning meeting by revisiting backlog priorities and assessing progress against the Release Plan.
- Attend sprint planning.
This is a long list of responsibilities. Note the choice of words. They are not just tasks or meetings – they are key responsibilities that must be fulfilled in order for the team to function properly.
Organizational skills are key here. As a product owner, I use a couple of different things to manage the volume and complexity of this role:
- A calendar for scheduling meetings and recurring events. Of course this includes daily meetings, weekly backlog grooming meetings and other ceremonies. I also schedule time to sit down by myself to prep for the next grooming meeting or to prep for the next sprint planning meeting. In doing so I am much more likely to actually do these rather than to forget about them or push them aside when a lot of other things pop up.
- A personal Kanban board (I use Trello) to keep up with requests that are made of me. This could include questions from stakeholders/users/clients, information requests from developers, research items, or any other tasks that I need to take care of. I find that a Kanban board helps with prioritization. It also helps with tracking items that are in progress, such as when I need to request information from users to make a priority or feature decision for the developers. Some of these activities cannot be done in one setting so tracking them on the Kanban board helps prevent them from falling through the cracks. Limiting personal work in progress can help avoid task saturation and the mistakes that ensue.
- The Product Owner must understand and develop a cadence for fulfilling their responsibilities. Operating in a haphazard manner hurts them and the team.
- Managing personal work in progress helps reduce mistakes and the number of things that fall through the cracks.
- No personal organization system is perfect, so I also make it very clear to the Scrum Master and the team to call me out whenever I have fallen short on fulfilling my responsibilities. I am there to serve them, after all.
Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.
What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.
Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.
Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.
How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.
For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.
Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.
What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.
A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.
The PO typically runs the grooming meeting.
What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.
What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.
- Backlog grooming is an essential activity. Resist the temptation to skip it.
- Schedule grooming meetings so that they fit In the middle of the weeks of the sprint.
- The entire team should be involved in grooming.
- Regular backlog grooming helps the PO establish a cadence for working on stories.
The team was eager to launch into their first release planning exercise. Wisely, the Scrum Master and Product Owner (PO) did not hand the team a list of already-written user stories. They knew that while it would take the team a little more time to identify and write the basics of each story, it would pay off many times over with the understanding and ownership of the stories created by this exercise.
The PO presented the first requirement. “Team, we need to provide the back office system with a summary of the day’s sales.”
A developer on the team eagerly grabbed a sticky note and jotted down the story.
While the developer’s willingness to jump in and start writing a story is exactly what the PO or Scrum Master like to see, what is wrong here? What should the PO and Scrum Master do in response to this story?
Part of the Product Owner’s job is to make sure the team understands WHO the feature is for, WHAT it is for and WHY it is needed. This is crucial because it allows the team to understand the vision for the feature, who it will benefit, and the value that it provides. This information can spur questions from the team and provide guidance as they weigh various potential solutions. Technical teams can very quickly jump to the HOW without fully understand WHAT they are building or WHY they are building it.
We all know the template for a user story: “As a <type of user> I want <some goal> so that <some reason>”.
Right away we can see that the story does not address who the story is for. As written, the story provides at best a modest sense of the goal, but with verbiage such as “Add task in scheduler to invoke C# application” it is more about the solution that the business goal.
Lastly, one of the most powerful components of a user story is the “so that” clause. This forces the PO to justify the story’s existence. What benefit will it provide? How will it help achieve the overall vision? If the PO can’t come up with a “so that” clause, there is a good chance that the story is not needed or is not well-enough understood.
Recognizing this, the Scrum Master jumps in and explains this to the Product Owner and the team members. The PO gives a more thorough explanation of the story, focusing on how it will help the business. The end result:
It may not be perfect yet, but it provides much more meaningful information than the original version. This story will trigger valuable questions from and conversation with the team and ultimately lead to a better product.
- If the story title is about the technical HOW and not the business WHAT, guide the team in rewriting it so that it reflects the business need or goal and not the technical solution.
- Don’t overlook the “so that” part of the story. It forces the PO and team to justify the story and truly understand it.