<- previous post in this series on stand-ups
While refinement may not be in the handbook of scrum rituals, it is still a prescribed practice. Argue if you want, but I am taking the liberty of calling it a ritual for this series. It took me years to accept the importance of refinement and the hour or two per week that it requires. What I realize now is that the ritual of refinement tests the discipline of the team. The need for the engineers, product and design to discuss a story, determine the edge cases and acceptance criteria and discuss the difficulties in implementation is imperative to team success.
Like my post on stand-up, this article is not on how to do refinement, but on how you fully participate in the ritual.
Preparation
On most teams, a combination of the product owner, design person, tech lead and/or scrum master will get the backlog together for a refinement session. Whether you are part of this group or not, you should review the list of stories yourself before the refinement meeting. The purpose of preparation is for you to get the ideas flowing on stories and create a mental picture of the upcoming work. Your time spent on preparation should be 15 minutes or less. Write down a list of yes/no questions that you can whip through while reading through each story and do it as quickly as possible. Do not point while preparing, because that should be done with the team. Here is a starter list of questions, but there are plenty more if you evaluate using the INVEST criteria:
- Does this story impact what you are working on now or another story in the backlog (internal dependencies)?
- Does this story rely on another team, department or third party (external dependencies)?
- If you were to write the code, do you have enough information to complete the story?
- Is this easily testable?
- …
Stay engaged
The argument against refinement is that it is boring and therefore should not involve the whole team for every story. That is for the team to decide, not you during the refinement. If you are in the room, your phone and laptop should be away and your attention should be on the story at hand. In a meeting where decisions are made with a group of peers, you should want to be engaged.
This is where your preparation comes in handy. As the team discusses the item, openly ask your INVEST questions. Your job is not to derail the conversation, but to give your feedback in a constructive way that leads to the ability to point the item honestly.
Note: If your team does not time box discussions in refinement, the meeting can quickly get out of hand. If a story has too many questions, move on and have a small team investigate the story and bring it back for the next refinement.
Point like you are writing the code right now
When you estimate work, I encourage you to estimate as if you are writing the code right now. This is extremely hard, especially in teams where you point by showing hands, cards etc., and then justify your points to other members of the team to find consensus. Often, and I do this too, you think about how others will point the story.
The problem with thinking about others is that it stifles the conversation. Let’s think about this with two stories coming up for refinement. We need two new pages to allow a user to click a button to do a thing. The first page uses the same pattern that is common throughout the code. The second story requires a slightly different approach because the back-end endpoint is not written. The team lead knows this because they have been in that code before.
The team lead points the first story a 2 and a junior engineer points the story a 5. The conversation that follows leads to valuable information. The points say that the junior engineer will need help on an item like this one. There is something (the pattern) that they have not yet learned or seen before. In the discussion, the lead tells the team that this pattern can be copied almost verbatim. Those notes go into the story and will be helpful when someone picks it up out of the backlog. The team decides to point the story as a 3 to account for the required learning of the pattern.
The second story comes up. What do you think will happen? Likely, instead of the 2 and 5 offered, both point as a 3. The lead offered the 3 because it was more complex than the first story, but assumes other people know. The junior engineer offered the 3 because it appeared the same as the prior story and the team said those stories are 3s on average. Did the junior engineer learn that thing just now between the first story and the second story? Of course not! If the junior engineer pointed like they were writing the code right now, they would have pointed this a 5 again. The team would discuss and maybe even compromise to the 5 after learning about the endpoint.
Are you the lead or the junior engineer in this example? (Both have some fault in the missed knowledge.)
Back to work
Refinement, while not officially part of the scrum rituals, is an important mark of discipline for you and the team. Whether your team practices refinement as a whole team or small breakouts, it is important to:
- prepare
- stay engaged
- point like you are writing the code right now
Have other tricks that you use for better refinement discipline?
In my next blog post, I will explore how you can rock the sprint planning ritual. Stay tuned!
