10 Experiments With Product Backlog Refinement
A Tale of Experimentation with one Scrum Team
It might feel frustrating to practitioners at times, but Scrum does not prescribe ‘how’ to do certain things. Many Scrum practices only emerge with experimentation, and this is in fact the best way to build a shared understanding of context with a Scrum team.
Over the last few months, I’ve been experimenting together with one team in relation to how we do Product Backlog Refinement. With this team, the right process for refinement has always been elusive. It was perceived by this team as inefficient, a time suck, and paradoxically, they viewed product backlog refinement as an impediment to delivery.
I know, right!? Work to be done for a Scrum Master :)
I should say at the outset of this post however, that this is a relatively happy story! Through experimentation, we’ve learned and improved, and this post is about 10 of those experiments. I’ve added ratings for each one: how useful they were to me and the team (marks out of 10), and how transferrable I think they could be to other contexts (low, medium or high).
Caveats: as always with experiments, context matters! These experiments are not prescriptive! Your mileage may vary! The point of this story is that you need to experiment to understand your own context better, and your team will tell you what is working and what is not working… Ok, let’s begin!
‘How We Do Refinement’ can be Elusive
Before discussing the experiments, let’s hear from the Scrum Guide about Product Backlog Refinement:
“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. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.”
Source — The Scrum Guide
For me, as a Scrum Master, that sentence in bold was the main challenge with our refinement process. To understand why that was, it might help to learn a little more about the context of the team...
Building Situational Awareness
Our team was dealing with multiple streams of work of varying size and complexity. They were aware of development practices like spikes, but not using them often enough, because of increasing pressure to deliver. There was often pressure to start work, and this meant design or requirements were not fully understood. The downstream effects were not good, and at one point we had quite a lot of conflict to deal with. It was clear changes were needed. So where to start… how about an experiment?
1. Agree a Definition of Ready with the team
As a former developer, I understand contract-based development. We agree a point of interface, and as long as we honour the contract, we’ll integrate successfully when we need to. A Definition of Ready follows a similar theory.
Our team decided the attributes and information they needed and broke down the definition of ready into two stages: ready for refinement, and ready for Sprint Planning.
User Stories were ready for refinement when they had a clear description of the ‘why’, Acceptance Criteria, and the description of the requirement in the ‘as a… I would like… so that…’. That part was easy. With this information we could estimate the stories in the backlog with Story Point estimation easily enough.
Ready for a Sprint meant that we understood all dependencies and design needs, and that we had broken down the tasks required to deliver the story, with time estimates on the tasks for all activities required.
Rating: 8/10. Transferability: High
2. Decide ownership, then allow others to opt out.
Unfortunately, refinement was a scheduled activity, and in the beginning, we included the whole team in every refinement session. Oh man, did the development team hate that.
In any given refinement session, there would be up to 11 people in the room, and the discussion would directly involve about 5 people. This approach did not respect the time of the team, and as a result they began to see the activity as an impediment to their Sprint work…
We decided to allocate ownership to requirements, and declare certain people mandatory for certain refinement sessions. This meant that others could opt-in if they wanted to, but otherwise, they could carry on with their Sprint work.
There was resistance to this from management at first, and it was mainly about the incorrect perception that all team members should participate in every act of refinement. This is just not true, and we should not prescribe it as fact.
Allowing opt in and opt out is also a practice of High-Performance Teams, as described by Richard Kasperowski. The developers were happy with this one.
Rating: 8/10. Transferability: High
3. Acknowledge the existence of hierarchy.
The Scrum Guide says there are only three roles in a team: Scrum Master, Product Owner and Development Team. Well, in our team we have an Engineering Manager and a Quality Assurance Manager too. If we wanted refinement to work, we needed to take this hierarchy into consideration.
This meant sharing every refinement invitation with the two senior guys on the team, and inviting them to either come along themselves, or delegate where they saw fit. This ensured that their roles were respected, and hopefully encouraged them to get the team more bought into the process.
Rating: 7/10. Transferability: Medium (does your team have hierarchy?)
4. Schedule PBR Sessions at Same time every day.
I sent out a doodle poll to the team one day, asking one question: “what is the best time of day for a refinement meeting?” Overwhelmingly, they voted in favour of 11am, so I decided to only schedule refinement ‘sessions’ at 11am in future.
This one was great because the team felt listened to. Before this, they were being bombarded with meetings at varying times of the day, and developers hate interruptions to flow. I know this, because I remember it myself! If an interruption becomes more predictable, then its impact is reduced.
Also, as mentioned above, the Engineering and QA managers were always invited, as were Scrum Master and Product Owner. The Engineering and QA Managers would forward or delegate the meeting invitations to other team members as needed.
Rating: 9/10. Transferability: High
5. Circulate User Stories 48 hours in advance
If I could recommend one change to your refinement process, it would be this: read the user stories before you arrive to discuss them. If you have some kind of requirements document like a PRD, even better!
When we organised refinement sessions ad-hoc, people would arrive unprepared, because they had not received details of today’s stories for refinement. We were reading User Stories together in the meeting room on a screen. Not the best use of time. When we started circulating the stories 48 hours in advance, we could ask everyone at the start of the session: have we all read them? This protocol encourages preparation on everyone’s part, not just the PO or the Scrum Master.
Rating: 8/10. Transferability: High
6. Slack Channel with details of Refinement done that day
This one appeared useful at first, but turned out to be something of a failure. As Scrum Master, I started using the #refinement channel to publish details of upcoming refinements, minutes from refinement meetings completed, and images of whiteboards if we used them in the meetings.
Unfortunately, these messages were a little noisy for the team, and they weren’t connected to the requirements in our issue tracking systems. I’m all for the transparency offered by Slack and I love the tool, but these messages were too noisy, and added little value to our busy team, who were working on higher priority stuff in other channels.
Rating: 3/10. Transferability: Medium (Requires Slack)
7. Kanban Board for Refinement Process
With this one, we started getting somewhere. The whiteboard showed us the various activities involved in our refinement flow of work, the numbers of items in each stage of refinement, and where each requirement was in the flow at that point in time. It also highlighted a dangerous fact: we were very busy with refinement, but no work was Sprint Ready!
This was a simple Kanban board, and was used by the Scrum Master, the Product Owner, the Engineering Manager and the QA Lead, while the development team preserved their focus on the Sprint Board.
I believe every team should understand the flow of refinement activities that are needed in order to get Product Backlog Items ready for Sprint Planning.
However, the team did not really take to the physical whiteboard. The reality of our team is remote working, so an electronic alternative had to be used if we wanted the whole team to be able to see it. This was a start, but it was not a successful experiment on its own.
Rating: 5/10. Transferability: High (Whiteboard needed)
8. Trello Board for Refinement Process
Once we had the refinement process visualised and agreed, we could move it to Trello... This meant that we could visualise the work in refinement at any time, remotely or in the office. Even on our phones!
Here’s where this tool started helping us out: it has a Slack integration… this means that, every time we moved a trello card representing an item in refinement, we could pop an automatic notification to the #refinement channel. Remember the noisy, detail-filled channel? It was now only receiving important updates… better!
Rating: 7/10. Transferability: Medium (Requires Slack and Trello inegration)
9. Prepare Refinement Schedule at Start of Sprint
We have a set time for refinement. We can see all the work in refinement, and what stage each one is at. We also have some hierarchy in the team, and we want developers to both own their work, and opt in to understand the work of others.
Next, we need to schedule what we are going to discuss, and on which day in the Sprint. We prepare this schedule with the Engineering Manager, and QA Manager in advance. This means we decide who needs to be there, and invite them to the calendar invitation. We also publish the schedule to the team.
This manages time better, allows opt-in, and gives great visibility of the upcoming priorities in the Product Backlog.
Rating: 8/10. Transferability: Medium (Quite context-specific this time)
10. Please Please Please: Allow for Spikes to happen
The last experiment is actually the one we did first. Please don’t push developers to start work if they don’t understand how to build it yet. Sometimes we need Spikes to reduce uncertainty. Better to take two days out of this Sprint to work on a little design than to get to 80% complete and realise we don’t know how to get the work done.
A spike is just a time-boxed investigation to reduce uncertainty around how to build a piece of work.
When developers started putting their hands up and highlighting the need for Spikes to clarify certain aspects of requirement design, we started getting much more predictable. Spikes are a learning aid, and an explicit admission to our team that development work is complex. Don’t rush to start if you have a nagging question about how to build something. Spike it!
Rating: 10/10. Transferability: High (Spikes are a way to acknowledge and reduce complexity)
My Current Picture
The picture below is what I have right now to represent our refinement process, and it attempts to encapsulate tacit understanding of all the experiments above.
It isn’t perfect (far from it) but it’s useful for me in my own context to elaborate the refinement process to the team’s stakeholders. It helps us build a shared understanding of expected lead time.
So that’s it! 10 experiments that have moved our refinement process forward, and that helped us all to understand our own situation a little better.
Have you found refinement challenging with Scrum Teams? What experiments have worked for you? It would be great to share war stories and get some discussion going.
Hope you enjoyed this post. It would be great if you could clap, comment, follow or share to let me know what you think! You can also find me on Twitter at: https://twitter.com/paddycorry
