Product owners are the custodians of requirements in an “Agile scrum product development” process. They engage with stakeholders and with the support of the development team ensure that the product backlog is ready for the next iteration/sprint. The role requires multiple skills to be an effective Product owner and one that skill that has led to the failure of product development is effective requirement elicitation. Also who occupies product owner role is often an issue within most organisations. The product owner as described should have gravitas and good stakeholder management skills to work collaboratively with all levels of management.
The scrum guides recommends that the product owner must own the product backlog and have the authority to say ‘No’ in a fearless or persuasive way. This is a minefield for most product owners I have trained and spoken to as they do their best to manage overflowing request from business teams. As the requirements are sent via many routes the product owner needs to record them and then add more information prior to a sprint planning session. The process of eliciting requirements is a new art for the newbie product owner and a specialist area for Business Analyst as they have been involved in the process of requirements elicitation. The process of eliciting requirements to some is organising workshops and interviews and asking questions to gain an understanding of the user needs.
Experienced Business Analyst advice that this process is iterative and never ends until the software is in the live environment where the user is using it to deliver value. Even at this point, the user’s world changes and complexity in their work leads to the need for new requirements. The big question is “how do Product owners learn the skills of requirement elicitation”. Here are 6 suggestions that should support product owners in their role
- Know your elicitation Techniques.
There are qualitative and quantitative requirement elicitation techniques that are suitable for capturing information from stakeholders. Qualitative techniques will collate information and data using Interviews, workshops, observation, scenario building. When applying the techniques the PO can follow the following steps: identify the information or problem to be resolve, select the right technique based on the stakeholders involved, plan for the sessions, conduct the session, document the information from the session, validate the information and continuously scan the business environment for any changes or dependencies to that requirements.
The quantitative techniques are used to elicit information where large groups of stakeholders are involved and there is more data required. These are surveys, special purpose records, activity sampling and similar to qualitative techniques the product owner can follow these steps: identify the information or problem to be solved, select the right technique based on the stakeholders involved, plan for the sessions, conduct the session, document the information from the session, validate the information and continuously scan the business environment for any changes or dependencies to the requirements.
The Product owner should also consider the outcomes from the sessions and how to present information and diagrams to the development team. The requirements elicitation exercise must be a rigorous and systematic process to reduce errors and customer dissatisfaction. The popular saying “the customer does not know what they want” is a result of the requirements elicitation process did not ask the right questions to pre-empt the customer to think more. There also no standard requirements elicitation process and this also have impacted the quality in the process. The PO can only get better by practicing and learning from books and attending training.
- Identify a requirements management tool.
The process of managing requirements requires a level of effort to keep the outcomes and output in the right place for the right time. The management of requirements is an essential part of the requirements engineering process as it requires that the most current version of the document is used and old documents are achieved accurately. Access to the documents should be regulated so that access is granted to the appropriate stakeholders. The PO needs to manage this process and use a document management tool that can manage, store and archive the requirements. A recommended tool is Microsoft TFS that provides an integrated end to software management lifecycle.
- Manage your stakeholders:
Stakeholders are the people who have a positive and negative interest in a product. They also have a stake hopefully in the success of the product as they have invested their capital in the business. They should be identified and stored in the stakeholder register. The product owner should carry out an analysis of the stakeholders and identify required communication channels for them. This allows for the communication planning and right flow of information during the process. The PO’s duty is to ensure that all stakeholder levels are management and monitored during the product development process and when the product goes into the live environment.
- Attend requirements elicitation training:
The PO can up-skill themselves by reading books and attending a requirement elicitation training. These trainings provide a platform for the sharing of knowledge and experience by delegates or the trainer. The PO can avoid mistakes made by the delegates and keep their stakeholders on their side. Courses provide a step by step guide to the process of requirement elicitation and a good understanding of techniques used for capturing requirements. Joining professional bodies to network and attend workshop sessions are also a great place to learn new skills for the PO role.
- Use the skills of existing BA’s:
The BA’s in the business or in the PO’s network can provide mentoring to the PO on requirements elicitation. Some organisations have found the role of the BA important in the product development process and have kept the role as a proxy product owner working with the lead product owner. The BA team will elicit requirements whiles the product owner makes decisions on which item should be delivered next with the support and advice of the technical team. In this instance the PO can depend on the BA’s skills and remove blockers from the process. Where there is no BA’s the PO should make an effort to connect with BA’s with the required experience and request for coaching.
- Practice, Practice, Practice and teach.
To be good at a skill requires hours of practice to gain more experience. The PO must apply a rigorous process for their requirements to be ready for each sprint planning meeting and that requires planning the elicitation process ahead of the sprints and engaging with the right stakeholders. The PO must follow through with the process and gather feedback from their peers on what to do better to improve their requirements.
Requirements are a vital link between the user’s world and the finished product. For the PO to have a high return on investment and make his stakeholders happy with the output of his work, they have to consider building strong requirement elicitation skills plus other skills that make an effective PO. The PO’s role is a very hectic role and not a desk role; it requires constant engagement with the business and users of the product to understand their needs. An effective PO is one who has identified their strengths and weakness on the role and they keep on developing their skill set to improve on their work.