Running a great refinement session in Scrum

Running an excellent refinement session in Scrum is one of the keys for the company to be successful. Without it, the organization will waste a lot of money and deliver their products late, lose market segment, lengthen development times, and impact the morale of its teams.

A refinement session is a key meeting in Scrum where ideas are clarified so that company or team members can find a solution for a problem a customer is experiencing or a hypothesis the team members have that believe will solve a problem.?In my opinion, there are 3 types of backlog refinement sessions:

1. Those that are done during the inception of a project or in early stages to refine the initial concepts of the product.
2. Those that are done within the Sprint cycle –every regular intervals– or what I call periodic refinements of the problem (what has to be done).
3. Sporadic refinements or refinements of the solution (how it will be done).

In this article, I will explain the last 2 points, leaving the first one for another time, as it belongs more to the beginning of an agile initiative itself.

There are several scenarios that I have come across in different companies, the first one is that no refinements of a product backlog are done, it is left for the last day of the Sprint or it is done within the Sprint Planning.

In general, this is the consequence of teams claiming not to have time to do this key session, having their focus removed from daily tasks as a result of constant changes or multitasking, or having no concrete user stories or problems to solve until the day before the Sprint starts.

I have seen the above situation occurs in companies where there are less experienced Product Owners, organizations with little knowledge of agility where they have mixed worlds (an area where Scrum is used and other areas more traditional), or where teams have huge internal or external pressure to reach a deadline.

In many cases even the same team members exert exacerbated social pressure on each other to meet the stipulated date, while in other cases, it is the Product Owner himself or the organization from where the signals come from. The important thing here is to identify from where the signals are coming, since the approach will be different in each case.

Periodic refinements of the problem

This session is held at regular intervals where the problem/hypothesis presented is analysed from the point of view of the WHAT has to be done. What does the client want, what problem is being tried to solve and when is it considered solved?

Please note that we do not talk during this session about HOW it will be done on a technical level, as this will be left to the last responsible minute, which is normally during the Sprint Planning session.

A recurring question is how often the refinement sessions have to be run and what the structure is.?I will give you some examples based on my experience:

• If you are a new Product Owner, new team, or company with little experience with Scrum, 3 sessions of 45 minutes maximum per week for Sprint is a good option.
• If you are an experienced Product Owner and team that has worked together with Scrum and on the same product for a reasonable period of time and has technical excellence (continuous integration, code standards, TDD, ATTD, excellent intra- and inter-team communication, etc.), you can think of 2 sessions per week of 30 minutes each one.

It's important to note that refinements are an exclusive time where the whole team comes together to focus on a problem. The Product Owner must continue after to refine the backlog with user stories for the rest of their day and most of their weeks. In fact, to get great results, a Product Owner needs a minimum of 80% dedication to the team and product. After all, success will depend on the dedication and quality of the refinements.

The latter is usually difficult to negotiate in organizations where most of the management is done in traditional ways or where people are more concerned about climbing the corporate ladder than serving the team/product.

Let's say that you have already booked a room for the refinement session (and yes! most companies have logistic and room availability problems when starting using Scrum) and the whole Scrum team is ready to meet on that day.

What should happen during the first session??

My first recommendation is that the team defines their rules of social etiquette beforehand, that is, what things will or will not be accepted during the session and make them visible (e.g. no cell phones or computers unless it is a family emergency, all the team together, being on time, etc.).

It is also recommended to work on a draft of the Definition of Ready. This is an agreement between all parties that stipulates when a User Story can be Developed in a Sprint.

No one wants or is healthy for a user story to appear unannounced under a sleeve one minute before starting a Sprint Planning. This would lower team morale, destroy confidence and bring about an undesirable number of negative effects in the short and medium term.

Here is an example of several elements of a definition of ready (DOR), but there may be many others:

• The user story is well defined.
• The acceptance criteria is understood and shared by all the team.
• The high level dependencies are known as well as the risks.
• The team has a high level idea about the current and desirable user experience.
• The story has an assigned size.
• The team feels comfortable that what they are really trying to solve is a problem for the customer .
• At least 2 refinements of the user story have been done before a Sprint Planning (Optional).
• The story has an assigned business value points to the user story (How much is the user story worth to the company and why).

Remember to keep it simple of no more than 5 or 6 points and look for improvement and simplification at regular intervals of time.

What should happen in the rest of the sessions??

In the subsequent sessions, the Product Owner should present the user stories or ideas about what problems need to be solved, what hurts the user and how it would make them happier. In my experience, it's always a good approach for the Product Owner to take all the user stories on Sticky notes and make them visible on the wall.

Using a computer tool (e.g. Jira, Trello, version One, etc.) causes a detriment of social interactions between team members and other people invited to the session. A sticky note can be scratched, moved, underlined, torn, drawn, and has a maximum size for writing which forces you to keep the "essence" or simplicity of what you want to solve.

A Scrum Master is essential here as she will invest time in advance to facilitate the session and to make sure that the Product Owner has everything in the room as well as the instructions for everyone on what he is expected to bring to the meeting.

It is important that a time box is specified for each user story to refine (e.g. 10 or 15 minutes) and the team moves to the next one at the end of it. This ensures the correct flow and that the team does not fall into a black hole where they focus on discussing a single user story throughout the session.?Here again a Scrum Master should timebox the team and see if all members participate equally.

It is very common for members that were Technical Leaders in the past that they participate and influence decisions more. In these cases, I recommend using an interaction map to balance the dialogues.

Be aware that members should not talk about technical details in here, they should focus on the problem to be solved or hypothesis and the journey for that particular user.

The team should analyze at regular intervals if the user story meets the Definition of Ready (DOR) and if not, see what steps would be necessary to improve that.

During the process, it is also advisable to assign a size to the story. In here, triangulation techniques widely used by Scrum teams are an excellent option.

This is a simple practice based on choosing a reference user story that is clear to the entire team and not too large or small and assigning numbers (user story points) or clothing sizes (S, M, L, XS) based on how much larger the others are compared to it.

In more experienced teams, sizing may not be necessary, but remember that it is a good idea to communicate to the rest of the company that something to be done is either too big or too small.

It is also a good idea that each user story contains Business Value Points, that is, a relative value of how much it is thought to be worth for the company not to have such a story available and what would happen if it were.

SIZE: 8 Business value: 400

As an AutoParking customer I want to be able to pay for my parking without having to get out of the car so that I maximize my time every day

Acceptance criteria?

• It covers at least 90% of the users
• It does not take more than 10 second to pay
• That the customer can know the remaining time

Remember that here we do not talk about how it will be done technically, but that the focus will be exclusively on trying to determine the validity of the problem or hypothesis, what you want to solve, its high level dependencies and risks.

The dependencies can be documented on each card or even if they are between two or more of them, you can use a thread to tie them, arrows or any other technique that makes it sense to the members.

Some examples of high-level dependencies are:

• People need to be contacted to verify the user story
• Business knowledge is not available right now
• Technical knowledge is not available right now
• Some information is missing
• Other user stories
• Depends on other teams

It is usual for software teams to start trying to solve the problem (How) in here ( e.g. see if JavaScript will be used, a server, the mobile phone, etc. during this session) but it is important to understand that these topics will be addressed later.

A?Scrum Master should be vigilant in maintaining the focus of the session to ensure that the technical solution can be open until the last responsible moment (when Sprint is almost about to start, unless the technical part looks too hard).

Addressing the technical solution here will most likely bring a loss of focus, leading to less flexibility in the solution.

Many companies also create the term Technical User History to be able to talk about technical/non-functional work during refinements. This term does not exist, it should be called technical work and this is not the time to do it either. The goal of a refinement is to align the team with the problem/hypothesis and to know if this is actually the root of the issue, to see the dependencies, and to establish the climate to focus on the solution and appropriate conversations.

During the session, many user stories are read one by one and the team is expected to be honest about whether they understand them, are well written, they are comfortable with the scope, etc.

Business specialists may even be invited to ask questions or provide relevant information.?If the team is new, a coach or a person with user story writing skills may be needed at this point.

There is also another type of element that is common during a refinement and these are called Spikes. These are research tasks where the outcome will be information or knowledge to make decisions, but should not be confused with technical implementations that are consolidated as part of the product.

“Knowing the number of people that would be affected if X is not there"

“Knowing if it is possible to use JQuery with the parking application"

They are also part of the refinement and it is recommended that they have an acceptance criteria. Remember that during the Sprint, Spikes tasks should not take more than 4 to 6 hours to be resolved.

Once this session is over, the Product Owner will take notes. The previous steps will be repeated in the next session. Feedback can also be obtained from attendees at regular intervals for continuous improvement.?Remember that the entire team owns the refinement session and not a particular role.

Sporadic refinements of the solution

Many teams wonder when technical issues will be discussed. This might lead to a lot of nervousness sometimes within the development team. In fact, many professionals recommend to do it during the Spring Planning meeting, but this is not a good idea.

Here is where sporadic refinements of the solution occur; they are essential and you must have the time and habit to make it happen.?The idea is that team members casually/informally start talking about possible solutions, problems and issues on a daily basis. This is what I call crucial conversations, which is far from structured planning.

Peter: John, did you see story X? I think JavaScript is a good alternative because if we used it in the mobile parking application there wouldn't be all these problems...

Jim: That's true, but we've never used it. Now that I remember, Alfonso used it before and he has much, much experience, today in the afternoon we can talk to him, and if so, the size of the story would go down and it would be easier to do.?

Pedro: Excellent! Let's do it and then talk to the team.?

This kind of refinement of the “how" should exist on a daily basis, which translates into conversations that make it possible to tune in and connect members with an idea or hypothesis and its possible solutions, as well as knowledge or technology constraints or other risks.

This can also be translated into conversations with other areas of the company, architectural areas, etc. The team can then provide its findings during the scheduled refinement meeting.

When there is no room for this kind of sporadic refinement, the team will try to talk about the technical part during the scheduled refinement or in the Sprint Planning session, which will make it endless.

Finally, if more than one team works on the same product (Scalability), some of the scheduled refinements should be done together or at least have members from both teams.

Remember that the latter should not be practiced with new teams; start small and then grow.

If you need to know more about how to empower Scrum and Agile teams within your company, please check my latest book on Business Agility (Leading Exponential Change).

Thanks for listening and good luck with your next refinement session,

Erich.