With the rapid increase in the adoption of Scrum and other Agile frameworks over the past several years, I’m not surprised that a few misconceptions and myths about Scrum have surfaced. While many more organizations embrace Scrum, many individual practitioners have not undertaken formal training. It’s the perfect environment for misinformation and confusion.
The table above shows figures from Digital AI’s 14th annual State of Agile Report contrasted with figures taken from its most recent report.
Misconceptions about refinement—the process of adding detail, order and size to individual Product Backlog items (PBIs)—can damage a Scrum Team's ability to deliver value to the business frequently. Let’s dive into a few of these myths so you can avoid them.
Related post: Don’t fall for these myths about refinement in Scrum
We have too much work in front of us to spend time refining the Product Backlog!
Many developers aren’t used to spending time on refinement. They may even consider the process a waste of time. In fact, a well-refined Product Backlog saves time because Scrum Team Developers can work with the Product Owner to ensure they size stories appropriately and only include the work necessary to deliver the sought-after value to the customer, and no more. “Gold plating” or adding functionality that is not needed is a form of waste. Just look at Twitter for inspiration. One of the most used social media platforms has a simple user interface with few unused features. Twitter’s streamlined user interface demonstrates that adding new functionality is not always the best answer. Twitter’s appeal is that it is uncluttered and straightforward. Sometimes the best functionality is the simplest.
Refinement only takes place in MEETINGS.
To deliver value incrementally, it is essential that the Scrum Team size higher-ordered PBIs so they can complete them within one Sprint. To get PBIs ready for the Sprint, teams should conduct refinement activities regularly. How they do it is up to them. Some Scrum Teams decide to have everyone participate in regular refinement meetings, while others identify a smaller group responsible. Still others have individuals refine particular types of PBIs. Whatever process a team creates, the outcome should be PBIs with an order, description, and size applied to those ordered highest.
We can’t deliver completed functionality in less than one month in our environment.
If your team is having trouble delivering individual PBIs in less than one month, or you have stories carrying over from Sprint to Sprint, you have likely sized them too big. Are you asking for too much functionality in each PBI? Have you tried having just one improvement per PBI? Breaking stories down to enable their completion within one Sprint is an art form that takes practice. Work with your Developers to break down each PBI to deliver a minimal amount of value - a bug fix, a single improvement, or technical debt. You will see that by breaking the work up smaller, you will improve the quality and predictability of the Scrum Team’s results.
Developers should determine how to deliver PBIs during refinement.
The goal of refinement is to create a PBI description (what the team will deliver), sizing, and order—not fully flesh out HOW to deliver each PBI. It seems counterintuitive, but the HOW may change based on WHAT work you pull into the Sprint. For example, say your team’s Product Goal is to paint a house. If the team resolves to paint the living room and the dining room during the upcoming Sprint, they might decide to have one developer pick up all the supplies from the store in one trip, rather than taking one trip to the store for each room.
We should not limit discussion in Refinement.
It can be easy to go down a rabbit hole during refinement, meaning that you can talk and talk and talk about a story beyond the point of adding value. You need to find the balance between discussing the story enough to understand and size it and dissecting it to the extreme. Fortunately, there are tools teams can use to help increase refinement productivity.
Consider limiting your discussions within the refinement meeting to a timebox. Some teams timebox discussions for each unique PBI to five to ten minutes. Find a timebox that, on average, results in productive discussion rather than allowing the opportunity to digress.
Another tool applies a facilitation technique called ELMO (Enough! Let’s move on!) If anyone thinks that the conversation has gone on for too long, they can call out “ELMO!”. The team will understand this as a friendly nudge to move on from a discussion that has gone on long enough.
If you find that your team is spending too much time in refinement, discuss it at the next Sprint Retrospective and consider adopting one of the above tools.
Conclusion
Finding the right balance of refined work for YOUR team is an art and is a strategic decision the Product Owner makes. The goal is to find the optimal balance for your team that eliminates the waste associated with investing too much time in the Product Backlog and having enough ready work to avoid creating idle time for the Scrum Team.
Both public and private classes are available. To learn more, contact Mary Iqbal.
