Seven Tips to Being a Great Product Owner


, , , , , , , ,

Every software product in development has a Product Owner who is in charge of supplying the requirements, and it is often misunderstood how important this role is. You can have the best engine in your car (the development team), but if you steer in the wrong direction, you’re not going to get to your destination.

Here are seven tips to make sure you’re doing this job well:

Represent the business

As the Product owner, it is your job to take requirements from any other business stakeholders, your own direct manager, feedback from the developers, and also the actual users of the software, and order them into a single funnel of prioritised work for the development team to work from. This is called the product backlog and is the main tool through which you can influence the success of the team.

Talk to the stakeholders

As well as taking requirements from the business, you also need to be able to report back to your various stakeholders with what the progress of the project is, and potential ETAs for features that they’re waiting for.

Maximise business value

Backlog prioritisation is all about making sure that the development team is always working on the most important thing that will provide the most business value. You can use a two dimensional matrix to help you with this decision. Think in terms of urgent vs important, and work in the following order.

  1. If a PBI (Product Backlog Item) is urgent and important, work on it 1st
  2. Work on important but nor urgent PBIs next
  3. Then urgent but not important
  4. Finally work on the PBIs that are neither urgent nor important

Since new work will constantly be coming in from feedback and other new ideas, if you follow this rule you will often find that your team almost only works on category 1 and 2 above, meaning you’re never working on unimportant work. Often you’ll find that if a PBI is urgent but not important, it will either no longer be urgent after a little while, or else it will become important.

Think in terms of Minimum Viable Product (MVP)

As a Product Owner, you have to be able to say when a feature is good enough for the team to stop polishing and adding bells and whistles, and instead move on to the next feature down the list.

This is especially important when budgets are tight (i.e. 90% of the time) to make sure that the business gets what it needs before you work on what it wants.

Be aware, however, that there is a slight cost in this, as if you want to come back to it later, you will have to let the developers get re-accustomed to that area of their code.

Manage Technical Debt

Technical debt is code or documentation that builds up over the course of any project, where some parts become legacy or shortcuts that were taken earlier cause headaches for work done later. Even diligent teams often find themselves with a buildup of technical debt as best practices change or new technologies emerge.

The solutions for this are varied, and include re-architecture, adding more measures such as unit tests or automated UI tests, and, most commonly, refactoring. Creating and prioritising these PBIs is one of the hardest things for Product Owners to do, as only the development team really knows extent of technical debt in any project, and often they won’t speak up about it because they caused the issue. See my other post about trust in teams to make sure you get full transparency in this.

My advice is to have a little bit of technical debt reduction in each sprint, as well as in your Definition of Done

Have a vision for the product

As well as taking requirements from others, the Product Owner should be in a very good position to have a holistic overview of the long term goals of the product, and this is known as the Product Vision. Keep this vision in mind as you’re shaping the product, to make sure it’s heading for a good destination.

Motivate and empower the team

There are plenty of ways for a Product Owner to impact the productivity and motivation of a team.

  1. Show gratitude for work well done or particularly useful features delivered
  2. Share the team’s success with others… always giving the credit to the people who did the work
  3. Be available throughout the sprint for clarifications to PBI Acceptance Criteria (i.e. the requirements)
  4. Try not to change your mind on priorities and requirements part way through a sprint as it can ruin the flow of a team that is on a roll

For a whole lot more, check out SSW’s Rules to Better Product Owners

The Five Things Every Scrum Master Should Do


, , ,

The larger a Scrum team is, the more opportunity for wastage there is, and so the more difference a good Scrum Master makes.

A team with a bad Scrum master can feel powerless, floundering, isolated, and overwhelmed whereas a team with a good Scrum Master generally feels well informed, connected, directed, powerful, and like they are working at peak effectiveness.

Be punctual

  • Set a regular cadence for the team.
  • The daily scrum is always at a predictable time so no time is wasted trying to organise it every day. The larger the team, the more important this is.
  • This of course also applies to the Review, Retrospective, and Planning meetings too.

Set a strict agenda

  • Tangent topics will come up regularly during meetings, and although sometimes these can be important discussions, they often take up a lot of time. Make sure that there’s never a time when 2 or 3 people are talking and everyone else is phasing out. If it’s on topic for a Scrum meeting, everyone should be involved, otherwise it should be taken offline (after the meeting with just the relevant people).
  • Make sure that someone takes a note of these topics as they can sometimes be forgotten otherwise.

Help your team

  • The people who know best how to make software are the people actually making it. If they raise an impediment, take it seriously and work towards a solution.
  • Help to motivate the team by showing appreciation for quality work. Doing this publicly often helps motivate other team members to strive towards the same level.
  • Encourage collaboration amongst team members. If one person is stuck, help them to realise that it’s always ok to ask for help.
  • Protect the team from excessive scope change. Adding a last minute Product Backlog Item (PBI) to a sprint should only be allowed if the team can drop an equivalently sized one.
  • Minimise WIP (work in progress) by encouraging the team to finish each PBI before picking up another whenever possible. This helps to minimise multitasking and ensure granular delivery of value to the stakeholders.

Help your Product Owner (PO)

  • A good Scrum Master should help the PO effectively communicate his requirements and priorities with the team. He should then reinforce those priorities and encourage the team to work in priority order whenever possible.
  • It’s a good idea to have high level conversations with the PO on occasion to work out what their more abstract goals are so you can help by making micro decisions for the team when appropriate. This way you can occasionally act as a Proxy-Product Owner when needed.

Coach your team

  • Make sure the team follows the Definition of Done.
  • Make sure the Product Owner creates well fleshed out PBIs with easy to understand Acceptance Criteria.
  • Ensure that the team has a uniform understanding of the estimation method being used (we use 2-Small, 4-Medium, 8-Large, where a Medium is about a day’s work)

The difference a good Scrum Master makes is well documented, and if you follow the above guidelines, you should be well on your way to empowering your team.

Along with my brother, I made a video on this topic which explains how the Scrum Guide defines the role of Scrum Master:

I’ve written many more specific tips on SSW’s Rules to Better Scrum

The Five Dysfunctions of a Team


, , ,

There are five interrelated issues that undermine the performance of a team, and they can be viewed from 2 angles:

The Negative Angle

This is popular because as managers we’re often looking for what’s wrong so we can fix it:

  1. Absence of trust. 
    If the members of the team do not trust each other, then they cannot be totally honest with each other.
    This is the hardest to fix as it’s often personality conflicts or deep-seated issues that cause this, but if you get this part right, the rest normally follows much more easily.
  2. Fear of conflict.
    Without trust, people will not have the healthy debates that are necessary to arrive at better thought through decisions.
    People who don’t trust each other will not openly say if they have made a mistake, or don’t know something, so you can’t get to the heart of any matter discussed. They are also less likely to proffer an idea if they might know another approach but are not 100% sure in case of looking silly.
  3. Lack of commitment.
    If the team has not aligned behind a decision, then the individual members who did not agree with the final decision will ultimately be less committed to that decision.
    This will lead to the bare minimum being done by that person, and a lot more micromanagement needed to get the desired result, which is a waste of good team minds and management effort.
  4. Avoidance of accountability.
    If an individual is not committed to the course of action, then they are less likely to feel accountable (or hold other people accountable).
    Another way of thinking of this is taking ownership. If they are not committed and don’t take ownership of a task, they’re much less likely to hold themselves and others accountable for successful delivery.
  5. Inattention to results.
    Consequently, they are less likely to care about the group results (and instead focus on achieving their own goals).

These are from the excellent book, The Five Dysfunctions of a Team by Patrick Lencioni.

I have found these principles so useful that I have printed this summary and I have it on my wall at work, both to remind me, and to help explain to others where team breakdown problems are likely originating.

The Positive Angle

Sometimes it’s also good to look at these from a positive side, so as a manager you know what you’re aiming for in your teams. These are the pillars that underlie exceptional teamwork:

  1. Trust and vulnerability
    When team-mates trust each other, they are not afraid to be vulnerable in front of each other, and will admit mistakes or shortcomings, allowing their team-mates to help fill any gaps.
  2. Healthy debate
    One of the main pillars of teamwork is healthy debates, where each team-mate feels empowered to contribute, ideas can be shared, and plans formulated.
    Part of this is each team member being able to let go of any ego and talk about the topics from an objective viewpoint, which is why team trust is so necessary.
  3. Commitment to decisions
    The outcome of the spirited debates should be a decision on a plan forward, and since each team-mate felt empowered to contribute to the plan, they should then also fully commit to the agreed decision.
  4. Accountability
    With everyone fully committed to the plan, they should then be comfortable to be held accountable (and hold each other accountable) to the KPIs.
  5. Attention to results
    If the group has a shared feeling of success, they will all strive for the same results, and will pay attention to if those results are met.

I have also written about this topic on the SSW Rule: Do you know the 5 dysfunctions of a team? 

arctree-5-dysfunctions-of-a-teamFigure: A nice info-graphic that covers this quite well