Explore topic-wise InterviewSolutions in .

One of the primary RESPONSIBILITIES of the product owner is to make the team aware of the market demands and how the priorities get realigned due to market situations. The product owner PROVIDES a clear VISION and sprint goals to the team to help them stay updated with the product. If there is any change in the backlog with respect to new requirements or priorities, it should be communicated to the teams. This helps the team to understand the bigger picture and what exactly is expected from them at that moment. 

The team even feels connected and understand their ROLE critically. It ensures that the team is building the right product and consequently delivering the ROI anticipated. There might be cases where the backlog aligned for a sprint GETS scraped off just because it is no longer required due to a fragile market situation, in this case, the product owner can terminate the sprint. The product owner is the voice of the outside world to the team and should ensure that all channels of communications are open and the team is very well understanding the market situations.

It is not always possible that the product owner agrees to what the team has developed. If the team has delivered the story/feature as per the acceptance criteria mentioned and has covered all the scenarios around that feature, then we can ask the product owner to accept the story/feature and anything which is not covered will be taken up in the new feature or a new story. But in the case where the product owner is not agreeing to the feature you delivered and it was part of the acceptance criteria then the product owner has all the rights to not accept the item. In this case, the team can take this up as the retrospective point as to where they MISSED, how it GOT shaped in a different way. The team should INTROSPECT what went well and how can they make it better. They should again set up a meeting with the product owner to GET a clear understanding of the REQUIREMENTS so that they do not deviate from what is expected.

One has to have control over the product backlog to be a credible product owner. The primary and critical responsibility of the product owner is to keep the backlog healthy and updated with prioritized requirements. If the product owner has no control then the team will not GET the right direction on what is to be developed. They will not understand the vision and goals of the product. 

Even it will impact the customers very hard, as they will not get what they expect to. No control also MEANS anyone can add or edit the requirements which might or might not be in sync with the customer. The backlog will look like a bunch of random things thrown together. One cannot see the product development strategy behind the Product Backlog Items which gain is a BIG risk to the development. The product backlog is the backbone for any SCRUM team, if it goes out of shape, the team and the customer will not get any output from the EFFORTS they are putting in. The Product Backlog eventually outlines the accomplishment of the product and assists as a master plan for the Scrum Team.

Every role demands some skills to meet the expectations of the position. In Agile, the role of a product OWNER is very important to keep the inputs and outputs up to the mark. Few of the essential skills to be competent product owners are:

1. Communication - It is predominantly critical for the Product Owner to have good communication skills that can adapt to different teams and behavior types. The Product Owner needs to WORK with the business to understand their vision and the development team to bring it to reality.
2. Commitment - The Product Owner should be committed to the project, vision, team and the business.
3. Vision - In connection with communication, the Product Owner should clearly communicate the vision between the small backlog items and the larger business goal.
4. Focus on functionality - A Product Owner has a focus on functionality, hours or even story points are less important. The goal of the Product Owner is to maximize value for the customer.
5. Available - A Product Owner is available for the stakeholders, the customers, the development team and the Scrum Master.

People skills are a must, relationship building, conflict management, client relationship management, vision, understanding requirements, clearly communicating the requirements to the team, and other skills are needed. These are MANY of the responsibilities/skills that POs must have to be successful. Yes, all the critical skills REQUIRED to be a product owner should be in a single person.

To become a product owner, there are no formal degrees that are being awarded but we do have CERTIFICATIONS which an INDIVIDUAL can go for. There are multiple platforms providing knowledge and certifications such as Scrum Alliance, Scrum.org or ScaledAgile. There are different levels of certification STARTING from basic to advanced. Each of them designed to cater to certain needs of the individual. The scrum.org provides Professional Scrum Product Owner I and Professional Scrum Product Owner 2. If you are working on a scaled environment, you can opt for SAFe® Product Owner/Product Manager certification. The training is of two days, during which the attendees will get an in-depth understanding of the Agile Release Train (ART), how it delivers value, and what they can do to effectively perform their role. Even though an individual ACQUIRES the certification still the in-built skills are the foundation of being a great product owner.

“A distant product owner works separately from the team. But distance comes in many forms and degrees. It starts with working on the same site in different rooms, and it ends with the product owner and the team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress.” – Roman Pichler

To work with a distant product owner, the team has to stay in constant communication to avoid any gaps in the INFORMATION being processed. Distant product owners should be on-site at least for the sprint planning, review, and retrospective meetings. They should have frequent video conferencing to help with face-to-face interactions, this not only instills confidence but also HELPS with getting the RIGHT product shipped. The teams having ‘Distant Product Owners’ should resolve their queries as and when they receive because any lag will cost them time in a sprint. It is always better to move from Distant to Co-located product owner as they are available runtime to ANSWER the queries and help the teams follow the GOAL.

In Agile, there is no rule on the ratio of the product owner and the scrum teams. A product owner is aligned with a single product and this person takes care of keeping it healthy. It might be a possibility that multiple teams are aligned to deliver that product, in this case, it will be overwhelming for the product owner to TAKE care of all the teams, answering their queries, sitting in their planning meetings, etc. 

In real-life scenarios, we try to align maximum of 3 – 4 teams per product owner, if it exceeds the number, one can have proxy product owners who can INDIRECTLY help the main product owner to manage the product and teams. With proxy product owners, there will be a NEED for coordination and alignment. All the proxy owner will need to stay in sync with the main product owner so as to achieve the desired results. Though it is encouraged to have a single Product BACKLOG and a single PO being responsible for return-on-investment when developing one product. Having a single Product Owner creates transparency and enables PROPER empiricism. It also depends on the size of the product, if it is too large, it should be broken down further to create sub-products and those should be aligned with different product owners.

“Teams need to understand who does what and how the various work fits together. This becomes even more important as companies grow.” - Brian de Haaff. 

The product owner role is really critical in an organization as it helps in translating the requirements to final PRODUCTS. As we have been discussing so FAR, it is a full-time JOB which requires constant collaboration with the clients, pulling up the feedbacks, working on the backlogs, helping the teams, etc. But if someone with an existing job title tries to fill in, he or she will not be able to JUSTIFY the role and in turn, the product and the team suffers. 

There might be delays in the feedback loops, the vision and roadmap might not get clear to the team, even the backlog suffers as it requires continuous attention. It is not advisable to take someone with already a title to play this role. The organizations need to focus on quality and time to market to stay up-to-date, hence, a person with dual role might not be able to substantiate such expectation from the role. Also, it will impede his or her efficiency in their former role. Though, in very small organizations where the team size is small and the teams are directly interacting with the clients, in those CASES, this dual role can work.

The Product owner can very WELL increase the value the team delivers. Continuous interaction is one of the factors that contribute to maximum value being delivered. Other factors can be –

• Domain Training – INVESTING time in teaching the development team about the domain, HELPING them UNDERSTAND the business and how it works.
• Vision – Taking out time explain the vision for the product and the organization.
• Value Delivery – MAKING the team understand the value being delivered at the story level. How the story can impact the overall product? How can the team deliver the highest value item? As a product owner, you should have these discussions with the team.

These not only encourages the team and helps them own the product but it also helps the overall business.

The product owner role has a large number of responsibilities, which can be broken down into tasks that can actually keep the product owner-occupied for full-time. Ideally, it is not ADVISABLE to have a product owner is not available for the team HALF of the time. But in CASES where they have a Part-Time product owner, they have to support a lot. There will be a few tasks which the team has to take over, like BRAINSTORMING alone as a team without the product owner and coming up with the queries. 

They might even have to do follow-ups which could have been taken care if they had a full-time product owner. Part-time product owner also becomes a challenge as the timely feedback from the client might not be possible all the time. In such cases, the team can take help from the BA (Business analyst) who can work as a proxy to help the team move forward. The BA can connect a regular interval to seek guidance from the Product owner. Usually, in cases where the TEAMS do not have their product owner co-located, they take support from the BAs.

As the name suggests, the PRODUCT Owner is the owner of the single product. The product owner focuses on the given product by constantly being in touch with the customers and through the expertise in the market understanding. Aligning a PO for multiple projects will IMPACT the quality of deliverable and it will also affect the individual playing the role of a PO. 

The focus gets divided, the time also gets broken down between different parties which in turn creates a mess for the product owner. It is not advisable to align ONE product owner with multiple projects as it also affects the strategy and timeline for the project. It is like asking an author to write two books at the same time, it is difficult to justify the efforts and we end up with chaos. It is difficult to multi-task, manage multiple stakeholders, manage his/her throughput of deliverables across products, prioritize the tasks across product TEAMS, etc. Though few of the organizations are aligning their Product Owners to more than one product, again, it then depends on their ability to DELIVER the right thing.

Every role in Scrum is aligned to an AREA, LIKE the development team takes care of the technicalities, code, quality, etc. in the same way the scrum master helps the team to DELIVER and stay focused in the same way the product owner has to take care of the business side. This role focuses on the business aspect, and hence connects with the stakeholders to define the EXACT requirements and passes on to the team for development. They have to understand the business, how it FUNCTIONS and how the market situation is. Therefore, it is all about the business, a product owner belongs to.

Every ORGANIZATION is different, they have their own HIERARCHY. Scrum does not provide any ground rule on the reporting structure for the product owner. In large organizations where the product is fairly big, they have product managers at the highest level, who are the main OWNERS of the product. At the team level, they have product owners who constantly stay in touch with the product managers. In this case, the product owners will be reporting to the product managers. But as stated before, there is no set criteria or hierarchy being followed at the organizations. Some even align the associates as per their position e.g. product owner at the lead level will REPORT to someone at the manager level.

“As a Product Owner, your JOB is not to manage 'resources' or 'tasks'. Your job is to maximize the value of your product! To create those features that deliver the most value for the products' users! In order to maximize the value of your product, you don't have to manage stuff like tasks, what people do on a daily basis, what the progress of the team is in a Sprint.”- Scrum.org

When the organizations open the position of a product owner, it is the product management team who helps the recruitment team in getting the right CANDIDATE. They access the candidate on their domain knowledge and analytical skills. The candidate might even be REQUIRED to go through where he or she can meet their cross-location counterpart. If the organization does not have a set product management team, the senior management can come into the picture and work with the recruitment team to get the best candidate. In some rare cases, where the teams are very MATURE, they themselves can be a part of getting their own product owner. As we have been DISCUSSING so far, every organization is different and so is their structure, it all depends on how they function. But majorly, the person who has good domain EXPERTISE and knows how to judge the other essential skills should be made to access the candidate.

Yes, if there is a SINGLE PO, can also take care of the RPO role, which is Release Product Owner. As there is only one person taking up the responsibility, the product owner will perform the duties towards the scrum team and also towards a higher role, let us see what an RPO does and what are the essential responsibilities:

• Creating a clear STATEMENT of vision, direction, release PURPOSE and goals
• Managing overall Product Backlog and publishing the Product Backlog so that the TEAMS can pull the work items in their release commitment.
• The features should be mapped with product roadmap to make sure the end result builds up as expected.
• Once the initial set of requirements are up, talk to the stakeholder and get their buy-in on Product Backlog
• Prioritization of Product Backlog and keeping it healthy throughout.
• Prepare appropriate Product Backlog to drive release planning
• Working on getting the ongoing release plan forecasting maybe for six months or a years’ time (as per the organization and client delivery expectations)
• Deployment & release readiness checklist
• Market launch split out to Product Management

The technical product owner is not a role but it DESCRIBES a person in a Product Owner role with a technical background and who works on a technology product. And business-focused product owners are more towards the functional ASPECT. It is always good to have a product owner with technical knowledge, they can understand the product and can create a STRATEGY for successful delivery. Also, if the Product Owner has the technical background, they can understand the technical blockers or impediments and accordingly visualize the impact on the release. But technical knowledge is just good to have, there is no expectation that the product owner should have it as an essential skill. 

Also having a technical background doesn’t mean that they have to jump in the code or work around the architecture. In the case of business-focused product owner, they totally rely on the development team for all the technical DISCUSSION and decisions. This HELPS the team to become self-organized, even the Agile principle says “The best architectures, requirements, and designs emerge from self-organizing teams. Nowadays we have started noticing the openings for a technical product owner, wherein the organization needs Product Owners to understand the company’s technology at a deep level.

Very large PRODUCTS need a complete product management team to deliver the working product through multiple TEAMS, in this case, the product is divided into verticals which are being taken care of by different product owners. But if the product is small and can be delivered by smaller teams, a single product owner can suffice. In this case, the Product Owner will act as a single point of contact and can be the face of the client as compared to large products. 

Single product owner with smaller teams have a high rate of efficiency and delivery due to clarity in vision and goals, there is a lot of transparency among the scrum team and the stakeholders. In a few instances, the RPO MAY also act as team PO for one of the Scrum Teams with the help from other team Product owners on other delivery Teams. Having a product owner CATERS to multiple teams impacts the team functioning as they have to WAIT for the availability of the PO, along with this even the product owner has to ensure they are giving enough time to multiple teams.

The success of the product owner depends on how much invested the person in this role feels and he/she understands the true meaning of being a product owner. But to measure the success, we can define some parameters LIKE:

• Strength of Product Backlog – If the product backlog stays healthy with prioritized items and has good user stories to worked UPON by the teams.
• Constant delivery of Value – Whatever the teams are delivering by the end of the SPRINTS, should be ADDING value to the clients.
• Attaining of Release Goals – At the start of a release, whatever the items teams commit should reach the end line. The goals should be met.
• Understanding of Product Vision by team members – The delivery team is able to understand and comprehend the vision from the product owner, they should be able to understand why are they creating the product, what value is it going to add to the customers.
• Defining a successful Product Roadmap is again important for the realization of the release goals.
• Lastly, the customer is satisfied.

There can be many parameters to access the success of this role, every organization has its own SET of KPIs for it. But most importantly it should the collaboration between the product owner and the teams plus the product owner and the customer.

Each organization is different and so is their structure. With an organization with a product management GROUP in place, the product owners can report to the product MANAGERS. But in an organization which is just starting up the practice of Scrum MIGHT not have a full-fledged hierarchy in Agile, hence, in this type of structure the product owners usually report to someone who is a level up in position, it can be the senior manager or the director. In case of SAFe environment, there is a proper structure with product group in place. Ideally, the product owner reporting should be made in such a way that they get full space on creating the vision, for innovations. It should bring out the best from the product owner ROLE rather than diminishing its influence. The organizations NEED to understand accept the importance of this role, hence, the reporting structure should not hinder the product.

As we have been DISCUSSING, the role of a product owner is REALLY critical and to make it successful, this role requires support from all ends, like management. The management can direct all the work for the teams through the product owner so that the incoming of items is from a single channel, thus, minimizing the haphazard behavior in teams.  Backing the product owner to make acceptance decisions during each sprint. The management can give feedback on product backlog content, priorities, and dates with a clear purpose. Development LEADERSHIP can assist the Product Owner in helping key stakeholders to understand and accept the need for making balanced choices on dates and/or feature content steady with definite team capacity. Apart from this, the management can HELP through coaching and skill-building activities so that the person in this role can enhance the competencies.

As discussed earlier as well, the product owner is the face of the customer, hence, it is really important for the product owner to stay in constant contact to understand the vision better and take updates on the product. The frequent interactions allow the product owner to stay up-to-date with feedback, MARKET situations or any change in the requirement. This not only helps the product owner but it also builds a level of trust and confidence among the customers. In a few of the organizations, this INTERACTION is being handled by the product managers, thus, these two roles can fill in the gap wherever required. 

The regular interactions also help in aligning the expectations from the customers, the product owner can, from time to time, showcase the developed product and ask for the feedback. In this manner, if something was missed out in the INITIAL discovery phase that can be catered now. If we talk about SCRUM, there are no product managers, but in agile, we have product managers sitting above the product owners and looking at the product at a higher level. The product managers are more into the market side whereas the product owner’s involvement is more with the development team.

The role of a PRODUCT owner demands a few BASIC skills like, good communication skills – this is the most important skill as the product owner has to work with the delivery teams and with the stakeholders. This role serves as a BRIDGE to fill up the communication gap, the Product Owner needs to work with the clients to comprehend their idea and with the development team to bring it to actuality. If they are not communicating efficiently, things can go crooked in no time. The product owner should be able to clearly communicate the vision between the backlog items and the greater business goal. 

Hence, the person should be able to see the vision and how it aligns with the backlog. Another important skill entails around guiding the clients and setting their expectation correct. Sometimes, the customers can demand something which might not be feasible, hence the product owner should be able to say no. And lastly, they should possess curiosity, the person should be ready to LEARN and ask ‘why’ for things being developed or should be able to ask ‘why’ to the clients as well. This way they can understand the business RULES better and can create a better vision of what the final product should be.

As per the Scrum Guide “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”. To MEET this, the product owner has to have mastery in many areas but only a few can be termed as critical because that is something which is a ‘must-have’ for this role. First, the product owner should have the ‘Business Analyst’ skill for concisely and correctly defining requirements but also have the domain knowledge and business knowledge to be a decision-maker to determine and prioritize what those requirements should be. Domain knowledge is the core subject for any product owner to master in their area and also KNOW the market and how the workflows are one of the critical skills required. 

Second, “PROJECT Management” skills to make good risk-based decisions on managing the project to make it successful from an overall business perspective (not simply MEETING defined requirements). The person opting for the product owner role has to strike a balance between these two provides the team with the OPTIMUM work.

As per the Scrum guide “A Scrum Product Owner is responsible for MAXIMIZING the value of the product resulting from the work of the Development Team." To meet this statement a product owner has to participate in several activities, talk to the stakeholders, do research work, etc. The product owner has to attend a meeting with the team which is PLANNING or pre-planning or any of the scrum ceremonies. To make sure the product owner ADDING value to these meetings with his presence, he/she has to spend a lot of time talking to various stakeholders and understand their problems and area of work. 

They also capture the metrics RELATED to the product backlog to understand the state and USE for reporting. They speak with UX designers or the Architect to identify how we can improve the system to remove the customer pain area. During the course of the day, the teams contact the product owner to clarify the doubts on requirements. Apart from this, there will be status update meetings for each project. Along with all this, the product owner has to keep the backlog healthy and prioritized.

As everyone in the agile teams, the Product Owner also has few challenges to TACKLE with, LET’s talk about a few of them:

• Missing product roadmap - Product Owners should create a product roadmap based on research, business standards, and best practices instead of constructing product FEATURES exclusively from a client’s customization requests.
• High-level acceptance criteria – The Product Owners should you INVEST model to create the structure. If the story is too much detailed, the team will fell that their questions are settled and there will be no room for discussion.
• Spending too much time in DEALING with product support instead of grooming the backlog
• Changing priority while sprint is in progress

Product Owners can ESCAPE these usual snares by working around the product roadmap, centering on high-value backlog items, defining crisp acceptance criteria, concentrating on grooming quality backlog item, and avoiding disturbing sprints.

In SCRUM, the product owner is the face of the client or the customer, hence the person playing the role will have the authority over the product being developed. The decision of what all will go into the release and when it should go is taken the product owner. Yes, the product owner has the veto over the release of user STORIES. This applies to all the business requirements or defects being DELIVERED. But the only thing which the product owner cannot decide is the technical debt. It is the developer who takes the ownership and releases with the product. The release DATES and the release candidates are pre-decided the product owner well in ADVANCE so that the teams can get time to develop and deliver. The product owner can accept or reject the user stories if they don’t meet the acceptance of the expectations.

The product owners wear multiple HATS in during their role, hence, there can be many titles which they can write on their business card. As they are the owners of a business or the product, the best-suited title can be similar to the highest ranks we have in an organization, like Product Captain, Business Marshall, Product Magnate. The product owners create a vision for the TEAM and help them walk the path towards attaining the desired goal, hence, the title can even be a Visionary, Servant Leader or Goal Keeper. 

They are often aligned with the strategic DESIGN of the roadmaps which makes them a Strategic Thinker or System Thinker. With the product development, the backlog over a period of time gets some in innovative ideas from the product owner which are liked by the clients too, and even the team works on them for launch, in such a case the title can be of an INNOVATOR. There can be several titles a product owner can have on their business card, it all depends on how creatively a person can think of.

In the role of a product owner, only managing the backlog is not the only job, the product owner wears different hats at different times to make this role a success. Product development encompasses tons of discussions with clients, with the development teams and with the leadership. Having a product owner playing a facilitator comes into the picture to ensure the team has a collective outlook on what needs to be done and getting the clients to have the RIGHT expectations on the output. 

The product owner can be visionary for the teams and they look up to this role to provide the product vision and HELP them stay focused to achieve it. For sure, the product owner drives the product for successful delivery, he/she will ensure teams are pulling up the right work and coordinates with the clients ensuring the alignment on the expected delivery. Being in a role of a product owner does not only involve a comprehensive understanding of the product but it ALSO demands the ANALYTICAL, strategic SKILLS and needs to comprehend the company’s technology and interface with the development team in order to successfully lead the approach for the product.

Canceling a sprint usually happens when there is a DRASTIC change in the priorities which means something which was EARLIER measured as important has MOVED down in the priority list and something with the critical priority has come up. If the requirements which were earlier considered as a high priority have been marked as low, will automatically impact the committed ITEMS in a sprint. 

Hence there is no point in continuing any further. It is actually not a good practice to cancel the sprint very often because in this case, it implies that the stakeholders or the product owner do not have the clarity on what exactly are they looking for. They are not able to prioritize the backlog and might need some help. There is a misconception that the sprint can only be canceled by the product owner, which is not true. The product owner can make a call to cancel the sprint but the other FACTORS are also to be taken into consideration. Once the sprint has been canceled, the first thing that the team will do is – Planning for the new sprint.

When we have the DATA points from the historic VELOCITY of the teams, we then can predict how much they can deliver in the upcoming sprints. In a release plan, we talk about the next three to six (or whatever is the release schedule) which comprises of the sprints. With the HELP of the historic data can align sprint with the numbers and subsequently can total out the effort the team can put in. 

“The release plan helps you track the development from sprint to sprint, anticipate if the relevant product backlog items can be delivered on time and budget (or how long it will take and how much it will cost), and to make the necessary adjustments, such as, reduce or remove a feature, or add a new team member to the team.” – ROMAN Pichler.

If the teams’ average velocity is 30, we can say in the upcoming release which has six sprints, the team can take up the work worth of 180 points. With the release planning, we can even tell ahead of time what will be the dependencies which might crop with during the development phase. The release plan differs from organization to organization but the ESSENTIAL part of the planning of iterations.

In agile, we talk about the quality at all stages in contrast to the waterfall where attention to quality was being given more towards in the beginning PART of the SDLC rather than later on. We make sure that in Agile, we have certain CHECKPOINTS to make sure whatever goes out, is as the quality standard. And hence, we set the definition of done where we set the parameters on quality. 

This definition of done is made as per the agreement between the team and the stakeholders and is fixed for a sprint (at the minimum). The stories COMMITTED by the team can only be marked as complete once it meets the criteria defined in the definition of done. In the definition of done, the team can set unit testing, code review, coverage, etc. as the parameters, if the team is working on accessibility, they can add the criteria in terms of compliance. Hence, the quality is frozen at the initial level so that whatever REQUIREMENT is shipped, it should adhere to the set norms. In the same way, we can have a quality BACKLOG to be entering into the sprints with the help of definition of ready.

When the product BACKLOG is being prioritized, there MIGHT be some factors which come in way of doing it effectively. To list out some, first can be, the time needed for COMPLETION, though the item is on high priority the development needs time to complete it and it is not fitting in a sprint. In this case, the product owner has to grill out the most important part of the requirement to be shipped first. 

Then we can have, Correlative or conditional relationship between urgently required tasks and other tasks. There MAY be dependencies between the urgently required tasks and other tasks in the pipeline. The team cannot deliver the prioritized requirement before resolving the dependencies. Another one can be, timeframe given by customers for feedback is not ENOUGH for the teams keeping in consideration the slippage. Even sometimes the customer emphasis is too much that the product owner has to guide the customer on what market needs are and how to get maximum return. Even the customers sometimes need direction to follow, this is where the product owner can pitch in.

Prioritization as a norm means “doing the first thing first”. Globally, the teams have been using SEVERAL methods or techniques for backlog prioritization. It is REALLY important that they understand few techniques that can help in way of prioritization such as MOSCOW, where a list of requirements or user stories are categories into – Must Have, Should Have, Could Have and Won’t Have. Once the classification is done into the 4 groups, the requirements are graded in order of preference within each CATEGORY. Another method of prioritization is the 100-Dollar Test or Cumulative Voting, in this method, the stakeholders are INVITED for a prioritization meeting and to make a list of options to be prioritized. 

All the stakeholders are given a finite amount of virtual entities (dollars, points, etc) which has to be divided among the given options (user stories, requirements, etc.) After that one can calculate the total units for each requirement. There’s another model which is comparatively more simple and effective – Stack Ranking. In Stack Ranking we consider each backlog item and place it in order of priority. The best part of this method is there can only be one number one, hence, helps to avoid a common issue where everything becomes a very high priority.

Non-functional REQUIREMENTS play an important role in the overall product development and delivery. These are the requirements without which the functional part cannot be termed as complete. Let’s first understand what a non-functional requirement is, “Nonfunctional Requirements (NFRS) define system attributes such as security, reliability, performance, maintainability, SCALABILITY, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.” – Scaledagile. There are different ways of handlings such requirements, like:

1. Create user stories in the backlog – The non-functional requirements can be similar to “constraints” we put on the system. It can be written in the same format as the usual user story.
2. Inclusion in DoD – The team can add these requirements as part of their DEFINITION of Done. If it is one of the parameters in the definition, it will make sure the NFR doesn’t get missed out and the team can keep track of it along with the original story.
3. Acceptance Criteria – Non-functional requirements may also be ARTICULATED as part of Acceptance criteria which are circumstances that a product must fulfill to be accepted by a user, customer or other stakeholders.

Whenever there is a need from the client or the customer, it has to be captured in some form, here we can TALK about product backlogs, and we capture the requirements in the form of user stories. It is one of the TECHNIQUES where the stories are added to the product backlog. The User Story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. It defines the type of user, what they want and why they want it, also it helps to CREATE a basic portrayal of a requirement. A user story template often uses the following type of format:

As a <role>, I want <feature> so that <reason>

The user stories are short enough to be accommodated in a sprint if not, they are further broken down into smaller pieces. It is written in a LANGUAGE which is UNDERSTANDABLE to both the client and the team, it is then the job of the agile team to take care of how to develop the code that will satisfy the requirements of the user story. To accomplish this, regular and close interaction is required from both the parties – the client and the team.

The scrum master role is very vast in nature, this role wears a wide variety of hat as and when required. At a high level, a scrum master is someone who will work with the Product Owner, help the team in sailing through the sprint smooth and work with the management in removing the IMPEDIMENTS. Now, this is a high-level view but if you dive further into it, this will grow like an iceberg. This role is very crucial and important for the team in making a successful delivery. The Scrum Master serves as a facilitator for both the Product Owner and the team. 

The scrum will help the product owner in prioritization and slicing of the FEATURES or the user stories, the scrum master can even use a few tools available to help the PO with backlog alignment. For the team, the scrum master will work to remove the impediments faced by the teams. Along with the delivery, the scrum master also makes SURE that the agile team lives by the agile VALUES and principles and follows the processes/practices that the team agreed to use. As per Mike Cohn – ‘The Scrum Master is often considered a coach for the team, helping the team do the best work it possibly can. The Scrum Master can also be thought of as a process owner for the team, creating a BALANCE with the project's key stakeholder, who is referred to as the product owner’.

The vision forms the foundation of any product, it is something which encourages and INSPIRES people to stay on the right path, hence it should be clear and firm; extensive and appealing. To list out few desired qualities of the vision, let’s look at the following points:

• Clear and firm – The product vision should be easy to interpret and creates a COMMON purpose for the teams. It should be able to give clarity on what’s in the future and it should not create confusion among the teams.
• Extensive and appealing – It should provide a very high-level view of where we want to go, and also provides the development team with space to COME up with ideas, to collaborative, to find solutions, to inspire to achieve more. It should encourage the team for better delivery in line with customer expectations.
• Brief and concise – The vision is not something which involves long WRITTEN paragraphs, it should contain only information critical to the realization of the product. It is not a list of requirements, hence, it should not cover the minute details. In simple terms, it should be short and sweet.

The product can only deliver value if it is aligned with the vision and goals. The Product vision defines the purpose of a Product, the intent with which the Product is being developed and what it aims to achieve for customers and users. When the product owner DISCUSSES the backlog with the development team, they refer to the order in the backlog which is based on the value. 

“The vision plays an important role in bringing a new product to life: It acts as the overarching goal guiding everyone involved in the development effort.” – ROMAN Pichler.

Vision provides a high-level view of what the future product should look like, it helps the development teams shape the product in a way it meets the required goals, as set with the customer. The product owner helps the team in identifying the sprint goals which are in line with the product vision so that the teams can deliver maximum value to the customer. The vision and goals are even linked to the MVPs (Minimum Viable Product). In Agile, the vision statement becomes a guiding light, the “what we are TRYING to achieve” statement that the development team, SCRUM MASTER, and stakeholders refer to throughout the project.

Like any other entity, the sprint also has few PROPERTIES like:

• Timeboxing – Almost anything in a sprint is time-boxed, whether it is a ceremony or the sprint itself. Timeboxing allows the space for discipline and closed boundaries for any planned activity. It helps the team to focus, remember the good old days when the actual study would start the day exam dates are published?
• Following a fixed time box in development creates a cadence, it also helps in gathering metrics on STEADY intervals, for instance, we calculate the VELOCITY of the team every time box (Sprint).
• Protected from any changes – Scrum says, once the team has made a commitment in the Sprint Planning, the scope of the sprint will be locked. Any changes in the commitment in terms of scope change is not ENCOURAGED. But if the change is small enough to be incorporated in a sprint, the team should pull it up as Agile Manifesto also talks about ‘Responding to Change over Following a Plan’
• The maximum duration of a sprint should be a calendar MONTH.

Next-gen product owner is not someone who just maintains and prioritize the product backlog with multiple FEATURES, next-gen PO is someone who plans how the whole product evolves and changes with time, how new product LINES evolves from the same product branch and how it REMAINS relevant and front RUNNER with changing market and TASTE

Yes. A DevOps team also works AROUND a PRODUCT. With automation, CI/CD, it becomes more important for DevOps team to understand business requirement and NEEDS and then automate the delivery pipeline. The business need could not be understood CORRECTLY, and doubts answered without a Product OWNER.

If the requirement is such that it may create new opportunity or HELP in GAINING the MARKET share for first mover (such as it happened for fintech companies like PayTM in INDIA during demonetization ANNOUNCED by government in 2016), the product owner should act on it. The  Product Owner has the authority and can cancel the current sprint if he deems it fit, adds item to product backlog and reprioritize it.

That’s a great position . But with great position comes greater expectation. 

The answer of this question will unwrap the product owner inside a candidate. Different candidate may answer it DIFFERENTLY. Someone may talk about adding new look and feel feature or adding UX (User Experience) etc, while few may talk about how gmail as a product would evolve, such as its integration to other existing product, or vice versa something like G-Pay integrated with Gmail or making it a one stop SHOP for all your needs – communication, collaboration, BANKING , shopping etc. This shows the VISION of the person.

Systems thinking means HOLISTIC thinking. It gives the complete VIEW. For a Product Owner, it is very important to have the complete view of the product, then only he will be able to design a product vision. Also if he has in an environment where there is a complete product management LINE of product managers above him, a holistic view will help him to understand why there has been CHANGE in the Product roadmap and why he should adjust the product backlog items

As a Product Owner, we should not out rightly reject any of IDEAS, nor can we ACCEPT all of them. Every idea that comes needs to be analysed. So ideation needs to be FOLLOWED up with analysis. The analysis can be done in several ways LIKE analysing through creating a prototype, working on pilot customers, based on EXPERIENCE etc. Based on the result of analysis, the idea should be added to the product backlog.

A PO can manage desire of various STAKEHOLDERS by coordinating and collaborating with them through discussion while designing product roadmap, seeking their input and feedback in designing and defining Product backlog ITEMS and preparation of SPRINT events. A consistent and constant collaboration WOULD help.

MAJOR stake holders with whom a Product OWNER interacts are – Customers, Sponsors, KEY decision makers, professionals, REGULATORS.

No, it is not required to RELEASE every SPRINT. While deployment is a PLANNING activity and could be per sprint or continuous, release is a business and strategic activity. The development team may continue to create a shippable product, the shipping is a business decision. The PO or the product manager will plan a release date , when it makes SENSE from business perspective.

It is very much required that the scrum team is aware of the CHANGES happening in market PLACE. It is one of the responsibility of the PRODUCT owner. The PO does it CONTINUOUSLY as a part of his informal interactions with development team and SM. He also does that through formal DISCUSSIONS and meetings.

While TEAM estimates the current SPRINT backlog, for FUTURE roadmap, which is highly flexible it is advisable, not to INVOLVE the team in estimation. The product LINE (Product manager, Product Owner etc) could do the rough estimation based on historical data.