Skip to main content

Using SBAR in code reviews

After the end of a messy sprint everyone was excited and scared to attend the sprint retro. The topic we were dreading the most came up - pull requests. It had been a sprint where few pull requests went through smoothly and everyone was picking up issues with every pull request. Stylistic things came up, whole features needed to be redeveloped, people were clearly annoyed, and you could sense the tension in the room.

Then, a suggestion by our non-technical product owner (who was a nurse and who had never been a product owner before) Why don't you use something like the SBAR technique?

Source: Jessica Chang's Blog

SBAR stands for 'Situation, Background, Awareness, Recommendation'. It's an acronym that started out in the military, but became very popular in medicine. 

Following SBAR in code reviews can allow smoother communication and understanding, as recommendations are made while outlining reasons why. For example:

Instead of

Change this to constructor initialisers instead of property initialisers

you could say

There are two ways to initialise these properties [Situation], however when we started this project, C# didn't have property initialisers [Background]. I know that property initialisers are a newer feature [Awareness] but for the sake of consistency, can we initialise these properties from the constructor [Recommendation]

Another example, instead of

Can we make this method accept an IList instead of an IEnumerable

you could say

This method is called by a consumer of this library and it's been setup to accept an IEnumerable [Situation], this means that the enumeration of the collection is deferred in the code that we control rather than the responsibility of the consumer[Background]. Making this method accept both an IList or IEnumerable will probably work in a similar way [Awareness] however, we want to know that the collection that is passed to us is able to be enumerated successfully to ease debugging and separate out concerns regarding what our library does and what the responsibility of the consumer is [Recommendation]

Following SBAR will slow you down in giving recommendations on code reviews. This is positive, as what I have found this does for me is that it makes me think twice about whether I'm correct in giving a recommendation or not.

It's important to note though that in many cases SBAR can be an overkill (factors include: culture, maturity, trust of teams). However, I have found that using this technique where I'm new to a team or where a team is new to code reviews really helps with being able to communicate my ideas. In the end though, it's always important to make a recommendation and follow up with reasoning. The SBAR technique is there to serve you and not designed to constrain your communication.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?