Agile
Epic Fail – Why Product Backlog Refinement is Essential for Scrum Teams?
Apr
Epic Fail – Why Product Backlog Refinement is Essential for Scrum Teams?
via Scrum.org Blog by Jochen (Joe) Krebs
This is the first part of a 2-part blog post series about dealing with very large Product Backlog items. Part 1 intends to focus on the Scrum Team, Part 2 will be released shortly after our Webinar on April 29th and will focus on the “Epic” challenges agile leaders are facing.
The Product Backlog is not an event in Scrum, but has its place in the Scrum Guide and therefore the Scrum Framework. For example, it is recommended that members of the Development Teams do not spend more than 10% of their capacity on Product Backlog refinement. Because Scrum is a framework and not prescriptive, Scrum Teams will decide when and how they refine the content of the Product Backlog. That fosters self-organizing Teams but requires a commitment, openness, respect, focus and often courage to implement. Those sounds like the Scrum Values to me, so let’s dig deeper:
Scrum calls items inside a Product Backlog simply a Product Backlog Item (PBI), but many Scrum Teams apply a popular technique called User Stories to capture the items. Those are then sized or estimated in so-called story points that follow typically the Fibonacci sequence. Many books and articles have been written about user stories and estimation, which I don’t want to repeat at this point. Instead, I would like to focus on one scenario of that particular technique, when teams estimate a user story as infinity. In the world of user story writing, those are then called Epics. Let’s explore in this blog post why these Epics often cause a headache for Scrum Teams. In part 2 we will take the angle of agile leaders. Part 2 will follow the webinar scheduled for 4/29.
Keeping in mind that a) Product Backlog Refinement is not an event, b) user stories are simply a technique and c) Scrum is not prescriptive, I often see the exact opposite when working with teams:
-
Weekly rigid meetings. low in energy and participation.
-
Heated debates about terms, meaning and the application of the technique rather than the user story itself.
-
Tools not accommodating the user story technique appropriately.
My intent is not steer anybody away from user stories, I am using user stories myself quite frequently. I also wanted to make sure that epics which have sometimes a bad reputation are generally not a bad thing. My goal here is to have a discussion why these oversized chunks require some special care.
Let’s start with the length of the refinement meeting for example. The energy and participation are often low and with only 60 minutes to spare, which is hardly ever enough time to explore any epics that are sitting lower in the Backlog. But Sprint by Sprint, we will eventually hit an item that hasn’t been broken down and detailed. The result is an epic that could then derail future Sprint Planning and making it difficult to craft a focused Sprint Goal. A typical anti-pattern is that user stories span across several Sprints. With two 60-minute meetings in a 2 week Sprint, we are way below the 10% limit of capacity as well. These scheduled meetings might be required due to distributed teams, but better facilitation (e.g. Liberating Structures) as well increasing the frequency of the meetings would produce a higher quality Product Backlog. Pairing during refinement activities and calling out good refinement practices in the team’s Working Agreements are also good areas to start.
Some software tool have a special set of features to deal with Epics. That is when you hear “This is epic is 70% done”. It becomes then a competition for the team to complete the epic. Doesn’t it sound better to you to have the large item 100% done? In hardly any cases though does that really make sense, because when Epics are broken down into smaller items, some of the smaller items appear to be low in value. Completing the progress-bar-race towards 100% completion means a Scrum Team worked on unimportant things. It also sheds more light on a principle of the Agile Manifesto “Simplicity–the art of maximizing the amount of work not done–is essential”.
Grouping items and labeling them as an Epic also distracts team members of having a focused conversation about a Product Backlog item. As they are mingled together with related items of this epic, there is the risk that the broader context of the epic is constantly distracting. In this example empiricism is threatened by bigger upfront design. Giving it a name like “epic” also makes it easy to keep the status quo of the conversation rather than digger deeper.
Slice n’ Size is a reminder for Scrum Teams as the Scrum Guide highlights to everyone that Product Backlog refinement is an ongoing process. So Scrum teams need to get a better handle on it. Product Backlog refinement is a team sport and if the process of refinement is stale and robotic do something about it. Slicing is also not limited to epics only and even items are already “in range” they could still be refined even further. The benefits of refinement don’t stop after epics have been broken down.
Also keep in mind, when lesser experienced Scrum teams face project pressure, Product Backlog refinement is often the first to suffer or being skipped. Not being a “formal” event does not reduce its importance. it is an essential element to have Scrum Teams focus on building the right product, instead of highly efficiently building the wrong product!
Join me the end of April, when we take a deeper dive into the challenges of oversized Product Backlog from an agile leaders point of view in this webinar. We will explore topics like value, innovation, risks, metrics and agile portfolio management. See you either then or maybe during my upcoming Agile Leadership Certification (PAL-E) series scheduled for the US and Europe.