Business Analyst Product Owner

Business Analyst Product Owner

Business Analyst Product Owner

This case study, Business Analyst Product Owner, is a part 2 of a series I am writing which follows Jane. Currently Jane is a traditional business analyst and we follow her as she is put into different roles within the Scrum team.

Business Analyst Product Owner

Click here to read part 1 of this series.

This study will be of her as she undertakes the role of Product Owner

within the scrum team. The things she needs to consider and when it will work for her and when it might not. We will follow Jane through this case study using some different personas which I hope will help you to understand and maybe even position yourself as a Product Owner.

What does a Product Owner do?

Before we understand how Jane can work and realign as a business analyst product owner we must understand the Product Owner role.

The best place to start is the Scrum Guide, which describes the Product as:

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

Source: http://www.scrumguides.org/scrum-guide.html#team-po

Let’s break that down and see how this could work for Jane?

What would Jane be naturally good at as a business analyst product owner?

  1. Clearly expressing Product Backlog items;
  2. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  3. Ensuring the Development Team understands items in the Product Backlog to the level needed.

What is Jane likely to be good at as a business analyst product owner, perhaps with some mindset changes?

The following things are requirements of what makes a Product Owner a Product Owner and I think they may come more naturally to some people then others and may even already be being undertaken in some traditional business analysis roles;

  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.
  • The Product Owner is accountable for what work is done first and priority decisions made as needed.

This may need a mindset change as Agile will break the deliverable items in a very different way to that which is expected of a Waterfall project. Agile takes a slice across the functionality and aims to deliver function to the end user in small iterations to maximise the benefits as early as possible.  Waterfall will typically group things with a view to moving from one thing to the next until at the end of delivery there is something that can be released. This new focus and mentality may need a shift in the traditional business analysts mindset. Estimation and priorities are no longer Must, Should, Could, Won’t as they hold no intrinsic value and mean very little when taken in the context of a whole delivery or a sprint. With that prioritisation in mind one may never be empowered to understand the difference between a must in position 1 of their list to a Must in position 20.

Priorities Must allow everyone to clearly see the priority of items in the list and with it be able to identify that work at the top of the list will be worked on first. There are a few ways to prioritise each with there own merits, the pictures below show the same fictitious list prioritised in different ways.

  1. Shows traditional MoSCoW ratings
  2. Shows a numbered priority from 100 being most important down to 0 being least important
  3. Shows an intrinsic value representing a cost value to the business for each week the product does not have this feature – I prefer this though see 2) more often.

Different ways to capture priorities

So what challenges do we think will face our Business Analyst Product Owner?

Well we still have a couple of points left which so far are not being addressed by our analysts natural skill set. The challenge with these items that are left are that they are as much in the new Product Owners domain as they are in the supporting structure of the organisation that sponsors them;

  • The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
  • For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

The change here is to have the Product Owner as the first and ONLY contact point for any changes into the Product Backlog. This can often be a challenge on both sides as the Traditional Business Analyst may not be ready for this nor may they have the right soft skills.  Typically this can be as challenging to an organisation as going only to that person to negotiate changes when a CEO urgently wants a feature into the system they may be inclined to go straight to the Scrum team but this cannot be allowed as this will adversely disrupt the team.  There needs to be this understanding from the Product Owner and the organisation to ensure this works as it should. Of course the development team may well have fun telling the CEO that they cannot talk with them and to repoint that person to the Product Owner; without prior knowledge that this may occur that could sully the relationship between the team and the CEO which probably is not a great place to be.

Summary

I think that one of the most natural fits for a traditional business analyst role when moving to Scrum is into that position of a Product Owner. I think Jane would be well suited there but needs to ensure that she is empowered to make decisions and respected enough to be allowed to do so with autonomy.

It would be very wise for her to protect her position and ensure that both she and her employer get the most from her role by attending some courses to help her understand her new role and to use the right tools to enable her a successful transition into this role. I would recommend something like the Professional Scrum Product Owner course and qualifications to help her along gaining a very good foundation in the role: https://www.scrum.org/Courses/Professional-Scrum-Product-Owner

Free Email Updates
Get emails of relevant posts like this in your inbox
100% Privacy. We don't spam.
Facebooktwittergoogle_pluslinkedinrss
© 2016: Audie. Ltd All Rights Reserved | Awesome Theme by: D5 Creation | Powered by: WordPress