Does your Scrum Team consistently find itself refining stories in Sprint Planning? Does the team have trouble getting more than 1-2 stories refined an hour? Do team members try to find any reason they can think of not to attend Refining sessions? If you answered yes to one of these, then your team is likely struggling with Refining. The good news is that it doesn’t have to be that way. In fact, it shouldn’t be that way at all.
Here are 7 ways you can help your team rescue their Refining sessions.
Make Sure the Team Understands Who Gets Value Out of Refining
When I ask teams who gets value when they conduct Refining, I often hear statements like “the PO does” or “nobody”. Comments like these can be an indicator that Development Team works under a limiting belief. A belief that doing something valuable means maximizing their time on keyboard. In truth, Refining is designed to provide the Development Team with value. That’s right. Those that often complain the most about Refining are those that actually stand the most to gain from it going right. The value comes in the form of increased clarity, reduced ambiguity, reduced risk, shared understanding, emerged complexities, and revealed dependencies. When done well, Refining can even play a key part in how a team actively pursues Knowledge Transfer goals on the team (more on that in a future post).
Reflect on Product Backlog Items in Your Retrospective
This is often a big help for new teams as they are still learning to get their heads around sizing. When they don’t get something to done by the end of their Sprint, they often think it’s about them being bad at sizing. In reality, it’s not about being good or bad at sizing or a size being right or wrong. It’s about whether or not the item behaved as they expected. If it behaved as expected, I usually tell teams to ignore it. There are bigger fish to catch. If an item didn’t behave as expected (if it took significantly more or less effort), then we have something to sink our teeth into. The team can ask each other if there was anything that they could have done differently in Refining to uncover what they know now. Doing this might help them emerge some standard questions they should ask or patterns that they should discuss on future items.
Have the Product Owner Provide an Agenda in Advance of the Refining Session
Having an agenda for any meeting is key to the meeting being able to accomplish what was designed to do. While the Scrum Guide doesn’t define Refining as a “meeting”, it does say:
“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.”
Any time we have a team collaborating, it’s important for them to have a goal. With a goal in mind and a timebox to achieve it (a meeting), an agenda becomes the plan of attack. In the case of Refining, the agenda can be a simple list of the “coming soon” items from the Product Backlog that the Product Owner would like the team to get their head around. In addition to sending the agenda in advance, the Product Owner can display it on an whiteboard, flip chart, or screen share during the meeting. When the team completes Refining an item, it can be checked off. When all the agenda items are checked off, the Refining session can be done. This technique helps provide the team with a sense of progress along the way and a sense of satisfaction when they reach their goal. If they finish early, all the better. You completed Refining and gave them the gift of time back in their day. If they run out of time, they can see if their agenda fit the allotted time and know what will likely be discussed at the next Refining session.
Have Team Members Pre-Read the “Coming Soon” Items Before Refining
This fits very well with the previous tip about a Refining agenda. With an agenda in advance of the Refining session, a team could establish a policy that every team member needs to read through the items before the session. People take in information in different ways and at different speeds. Some are note takers. Some are visual thinkers. Some need to let things percolate. Giving people the chance to be themselves and take in info their way first will help them all arrive better prepared. Caution, don’t have team members chime in with questions by email in advance of the Refining session. The goal isn’t for them to start a conversation before the session. It’s to prepare them for the conversation they will have together.
Create a Definition of Ready for Sprint Planning (DoRsp)
At times I describe Scrum as a simple system. It has input, throughput, and output. Paying attention to the condition of the input (items in your Product Backlog) can help increase the throughput (items in your Sprint Backlog getting to Done) and result in higher output (value being delivered to users). I’m not talking about having perfect User Stories that have everything stated in an almost spec like fashion. I’m talking about having some checks and balances in the process that gets things ready for Sprint Planning. To cut to the chase, the goal is to remove refining behaviors from Sprint Planning. Refining behaviors are things like writing new stories, generating acceptance criteria, and sizing items. To move Refining behaviors out of Sprint Planning, a Scrum Team could establish a policy about what must be true about a Product Backlog Item in order for it to be eligible for them to consider pulling it into a Sprint during Sprint Planning. I refer to this as a Definition of Ready for Sprint Planning (DoRsp). A generic DoRsp could be something like:
– The item is entered in the Product Backlog.
– The item has been ordered in the Product Backlog by the Product Owner.
– The entire Scrum Team understands the value of the item.
– The Development Team generated the Acceptance Criteria for the item.
– The Development Team sized the item.
The team will also need to be aligned on their behavior when something doesn’t meet their DoRsp. Do they consider it not eligible to be pulled? Do they jump through the hoops to make it eligible? There are times when things come in after the last Refining session that are very valuable and need to be acted on by the team. If the default, however, is to always jump through hoops, it’s a sign that the team might have some more work to do to get Refining behaviors out of Sprint Planning.
Create a Definition of Ready for Refining (DoRr)
In the same vein as a DoRsp, a team can also help define the conditions that things should be in before they are even brought into Refining. If we also think of Refining as a system, we want the things coming into Refining to be ready for the Development team to refine. If things are not ready for Refining, bringing the items to a Refining session could slow the team down. Again, I’m simply talking about having some checks and balances in the process that gets things ready for Refining. I refer to this as a Definition of Ready for Refining (DoRr). A generic DoRr could be something like:
– The Product Owner has discussed the item with the requester and/or user.
– The Product Owner understands who will use the item when it is released.
– The Product Owner understands what the user wants/needs.
– The Product Owner understands why this is valuable.
– The Product Owner captured any notes from the discussion that would be valuable for – the Scrum Team to reference.
– The Product Owner ordered the “coming soon” items.
Notice the trend in the statements? A DoRr indicates that there is a good amount of work to be done by the Product Owner to wring out the initial ambiguity of the Product Backlog Item. To be clear, I’m absolutely not suggesting that the Product Owner should flush out all the specifics of the solution. The Product Owner should understand and respect that they are the WHAT and WHY role and the Development Team is about the HOW.
Cut Down on Long Debates Between Low-End Neighbor Numbers
If you’re using the Fibonacci sequence or a close variation, there are numbers at the low end of the sequence that aren’t orders of magnitude different. For example, the 1,2,3 in Fibonacci. If you’re using Sizing Poker and the edge cases that emerge are things like 1 and 3, you’re actually really close to alignment. There’s no need to run down the clock debating efforts that are that close. I would still recommend that you encourage the edge cases to reveal their assumptions, but it should be a quick convergence after that discussion.
What can also help with low end neighbor is to potentially remove the 2 card from everyone’s Sizing Poker deck. This creates a slightly larger order of magnitude gap at the low end. In my experience, that a slightly larger gap seems to help keep teams out of less fruitful low end debates.
There you have it. Seven tips to rescue your Refining sessions. If you feel like you team struggles with Refining, give these a try. If these ideas help you get a handle on Refining, share what worked with other teams in your organization. What your team learns can be a great source of continuous improvement for other teams.
Let me know if you have any comments or questions. You can reach out to me via email at FrankS@FreeStandingAgility.com.
Thank you for reading.
Comments are closed.