Being an effective Product Owner depends all on you, on developing your skills and proper management of your time. Dev team members always help to be successful but to be effective is always our duty.
Deliver Features or Deliver Projects?
Usually, the dev teams are delivering features to the business. A fact! Usually, the business is requesting the features. Another fact! Also, the features are requested based on the needs of the end-users at that specific moment. As we all know, the world is changing continuously and progress is at the core of all the targets we have.
But is this the right way? I am not sure. If we always deliver what the business wants, at some point in the future we will have contradictory rules. If we are working in an airline company, for example, we will receive a request “please, if the departure date is too far away (for example 1 month from now), please do not raise tasks for flight preparation”. Later on, most probably, you will receive another one “If the flight is for a platinum member, make the flight arrangements ASAP with priority”. So, what will happen if the flight is scheduled for the next summer and it is for a platinum member? We are asking this question now but if you receive the requests in a year period, most probably will not comply with the previous rule. So, the best approach here is to make a matrix of rules and to extend it with the business needs. Usually, for the first, second, third and the following requests, there will be no budget to implement this matrix of rules and all the rules will be implemented in their own way and at the end of the day, you will deliver a spaghetti of rules which will contradict in one moment.
From my experience, working in a bespoke software development company I prefer to set goals and deliver projects instead of delivering features day by day. Making this work is not very easy because it’s always related to investing more money than someone wants to pay.
The dev teams are good at estimating. Not precise but good. Estimation is easy to convert into money. Everybody wants to know what should be the price of the purchased software product/feature.I believe the most important knowledge which our clients need is how much it will save or the Return of Investment (ROI). If the calculation of the ROI is not easy, we can always fabricate some KPIs (Key Performance Indicators) and based on them to calculate the ROI. For instance, if we are developing some automation for processing of documentation or control, which is currently manual, we can set some times which are at the average base, multiply by the amount of the documents on a monthly basis and the result will be the saved time. With the usual salary in the partner’s country of operations, we can present to the client what is the ROI per month, year or century. With this calculation compared to the cost of the feature, you can present a better view and better proof to the client to purchase the feature.
Challenge the Project Managers
The Product Owners (Scrum roles) are dependent on the Product/Project Managers (PM). They are receiving the main specifications from the PMs and have to break them into user stories. Then, the Dev Leads have to break down the user stories into technical tasks. Finally, the tasks can be developed.
The Product Owner must provide tasks for the team. This is the reason that he/she has to be in touch with the PMs and extract all the specifications for future projects. Then he/she can extract the knowledge for the tasks, break them down into user stories and refine them with the team. This process should include mainly Business Analysis skills. The knowledge base for the project and its features should be helpful to think from a project to product perspective. This is the key to make goals and follow them together with the team and the stakeholders.
When the backlog is full, the product owner is happy, otherwise, he is under pressure.
The product owners have to be sure that the team(s) is provided with described and estimated tasks for the next period of time. If it uses Scrum methodology for management and the sprints last one week each, the backlog must be filled with tasks for at least one week for the whole team. The backlog also needs to be ordered by priority. The most important tasks (the next tasks) have to be on the top of the backlog.
From my experience, the tasks should be grouped by fixed versions or deliverables at the time of writing them. The most challenging part of this grouping is when the dev work is in a mixed process – development and bug fixing at the same time. When a bug from production is reported, it should be included in the most common release. This should not be a rule! Firstly, the impact of the bug should be investigated and then it can be included in the most appropriate deliverable. Also, if you are working on a monolithic application, the bugs from the finance should impact the QA phase if they are included in a non-finance release. So the business impact is the key and it should drive the choice of the release. Don’t forget the ScrumMaster certification. It is always good to have certificates. At least you can place them in your LinkedIn and say “Mom, I have a new sheet of paper with my name on it”. There are several good courses to get a certificate but I advise you to use the authentic ones like scrum.org.
Useful Tools for Product Owners