SQL Server Product Owner advice

Reading Time: 5 minutes

In this post I thought I would share some SQL Server Product Owner advice based on actual experience. Because I am aware that is still fairly new for a lot of people compared to the more traditional SQL Server roles.

In fact, I have been asked about it a lot recently whilst at conferences. Because people are aware I have done a SQL Server Product Owner role for a client, which I discussed previously here.

Now, for those of you who don’t know a Product Owner is a role that is typically associated with the Scrum framework. However, in some enterprises Product Owners roles can exist in teams that use other frameworks like Agile as well.

It’s most commonly encountered by SQL Server professionals working in teams as either SQL Server Developers or Engineers.

However, other SQL Server professionals can have Product Owners in their team as well. Especially those who are working in a DevOps related way.

Where does Product Owner fit into hierarchy?

Now, one of the most common questions I get asked is about how the role relates to the rest of the team. For instance, I get asked if it’s an architect or a team lead kind of role.

In reality, if you stick to the proper way of Scrum the team will be flat structured. Which basically means that everybody is equal and responsible.

SQL Server Backlog items

A Product Owner is responsible for organizing work for the team to do. Typically, these are items to do during sprints, and in Scrum they are called Product Backlog Items.

In reality, Scrum has its own hierarchy for these Backlog items. At the top you have an Epic, which can contain or more features. Each of these features can contain one or more backlog items.

You can think of this hierarchy a bit like grandfather, father and son. However, for some teams this hierarchy is not set in stone.

For example, I know some people have backlog items which don’t belong to a feature, and some cases not an epic either.

Part of the Product Owner role is making sure understands what needs to be done in these items. So that the team can agree that the item can be worked on in a sprint.

Just to avoid any confusion, a sprint is an agreed amount of the time for the team to perform work. For example, a two or three week period. It’s common for teams to name their sprints. So, it gives you a chance to be imaginative.

Product Owner communication

Another part of being a Product Owner is that you have to communicate to people at various levels. For example, stakeholders for the Backlog Items that you create.

You can think of stakeholders as being customers you are delivering items for, they can be internal or external to your team. Depending on your company and its structure you can end up speaking to others as well.

For example, other members of various teams and stakeholders. You will probably end up talking to other Product Owners as well to align your backlog items.

In addition, you’re going to have to make sure your written skills are good as well. Due to the fact you will be generating the backlog items for your team.

Of course, you’re going to have to speak to your other team members as well.

Meetings advice

In fact, another crucial part of being a Product Owner is attending meetings. So, make sure you are prepared to attend a reasonable amount of them.

Once upon a time somebody in the SQL Server community asked me if a team loses out if a technical person does the Product Owner role. Based on previous experience, teams appreciate it more if they can speak to a Product Owner at a technical level during meetings.

If you are using Scrum then it is essential that you have a good working relationship with your Scrum Master. You’ll find that the better your relationship is with them, the better your team will perform.

Setting priorities as Product Owner

One thing you will have to be good at if you want to become a Product Owner is organization. Because a Product Owner is ultimately responsible for prioritizing these work items. So, organizational skills are a must have.

In fact, even though you talk to stakeholders about the priority of work items, you will ultimately be responsible for defining the priority of them.

However, you may find that a level of Portfolio Management is involved. Which is where there is a Portfolio which is a layer above you to align the priorities of multiple teams.

If that is the case you will have to align your priorities to that of the overall portfolio of your department or business.

Analytics advice

If you work with SQL Server then you are probably used to dealing with data. Which is good, because a Product Owner is expected to show data in a variety of ways.

You need to show this data for others to see what you have done and what you are working.

In addition, as a Product Owner you are going to want to look into the analytics yourself. For example, in Azure DevOps you can get some really rich analytics about the work your team does.

Transparency as Product Owner

You may have seen more these days that people need to be transparent. If you want to be a Product Owner you are going to have to be extremely transparent about what your team does.

For example, encouraging the stakeholders to see the progress of the work you are doing for them. In order to do this, you have to give them access to those items in whichever items you will use for your boards. In my case, I use Azure Boards which is a feature in Azure DevOps.

Further research advice

If you’re going to become a SQL Server Product Owner and you are new to the role I recommend you do further research. If you do this instead of just reading my SQL Server Product Owner advice, you will be well prepared.

In the beginning, your research should be into the role and whatever framework you are using.

However, if you want to go that extra mile and do the role well you will have to do extra research as well on occasion. For example, if you want your team to adopt something new you may have to learn about it yourself.

Afterwards, you will be in a lot better position to create the backlog items which I discussed above. In addition, if you are really enthusiastic about it then it will encourage other team members.

Final word

I hope you all have enjoyed me sharing some real-life SQL Server Product Owner advice.

If you have any questions relating to this content than feel free to leave a comment. In addition, you are more than welcome to ask me privately through the contact section on this site.

As you can see here, I am also speaking about Azure DevOps with Sander Stad at SQL Saturday Iceland. So, if you are going you can also catch up with me there.