Explore topic-wise InterviewSolutions in .

The best (and perhaps the only) way to deal with uncooperative stakeholders is to WIN their CONFIDENCE by engaging them through regular meeting and DISCUSSIONS and demonstrating the value of agile product development. ID it still fails, the product owner should seek HELP from SPONSOR.

When valuable new features are competing with bugs and technical debt in a product backlog, as a product OWNER, with every sprint, along with the features I will INCLUDE a limited number of the most important bugs and the most pressing ISSUES caused by technical debt. Based on the product, we can also have some basic THUMB rule set for it, such as allocating 10% of the resources to bugs, 15% to technical debt and rest to new features.  

The answer MAY vary from person to person and organisation to organisation. If the person says that they spend 50% of their time on user research, that’s excellent. However, if a product owner says they spend 10% or less time, it’s not good. This means they are not doing ENOUGH customer EXPLORATION and feedback and MIGHT also be IGNORING changing market condition.

Cone of UNCERTAINTY shows, how much is known about the PRODUCT over time. Its more variables and less fixed INITIALLY but as we move, it will have more fixed and less VARIABLE.

The answer will VARY from candidate to candidate based on their exposure and the size of organisation they are working in. For a small organisation the PO might be directly involved in CREATING the roadmap however in large organisation, he would be someone whose INPUT would be required.

Typically the answer would evolve around : Continuous exploration – Taking feedback after every RELEASE , checking how the features has been perceived by the market, ANALYSING competitor’s offerings and our customers’ reaction to it. Not doing upfront design and freezing the requirements.  Having features variable for future releases and creating a roadmap which will follow Cone Of Uncertainty.

MoSCoW is a very BASIC PRIORITISATION technique. Most of the PBI will be falling under Mo and S. An experienced PO would be using various other WAYS to differentiate between Mo and S. POPULAR one is WSJF – Weighted Shortest Job First. WSJF = Cost Of Delay / Job SIZE.

MOSCOW is a Product backlog refinement technique, where Mo stands for Must be, S stands for Should be, Co STAND for Could be and  W stands for Won’t be.

A Product owner is SOMEONE who focuses on product vision, roadmap and changing priorities. He does not GIVE the solution. A Business analyst LARGELY translates the product vision into solutions and at times recommends different ways or solutions. While Scrum does not requires a Business analyst, there is practise in many organisation to have a PO, who is focussed on product part and a BA, at times called as BA or even proxy PO, who is a techno-functional person who HELPS in defining then acceptance criteria, a solution ETC.

The answer will vary a bit from candidate to candidate. If he is in a large organisation where there are multiple TEAM working together on the same product lines, he will talk about his PEERS and COORDINATION, the product LINE chain (something like Product Owner, Area PO, Product manager, Chief PM) or in case of distributed agile team, he will also talk about Proxy PO at off shore. If he is from a SMALL organisation, he will talk about him directly discussing and coordinating with Business executive and Sales guys.

Agile has helped the teams to MANAGE changes within the development process. The Agile Manifesto talk about the ‘RESPONDING to change over following a plan’ and the Agile principle says ‘Welcome changing requirements’. The Agile team has to strike a balance between responding to change and working as per the sprint plan. If the change is being REQUESTED by the Product Owner, the team has to decide if they should accept it or not. Some of the deciding FACTORS can be – the volume of change, if the change is too big, the team might ask the Product owner to break it into parts or commit the whole in the next sprint. Second, time of change, if it is inserted early in the sprint, the team consider it rather than in the end. 

Third, if the sprint commitments are getting changed or any new changes are introduced frequently, it should be addressed with the Product Owner.  Whatever might be case, it is a negotiation between the product owner and the development, the team gets to take the final call on the acceptance of change.

YES, for sure, if the PRODUCT owner is missing the control, it will impact the overall product and even the WORK of the product owner. In this case, the product owner has to set up and understand the role and RESPONSIBILITY of being the PO for a scrum team. It might be a possibility that the product owner is not getting the space to work and his powers are being controlled. Hence, make sure that the person called the Product Owner actually OWNS the product. He has to create the product road map and set business goals for the upcoming quarters. As a product owner, you should have good communications flowing with the stakeholders along with good cooperation. The product owner has to work in enhancing the product backlog and keep it aligned with the market NEEDS. It will be difficult for a product owner to handle messy backlog which lacks control.

Yes, it is a full-time job, where the PRODUCT owner works with the team sprint by sprint for effective delivery of the COMMITTED work. In the case of Release Product Owner, it again requires full-time INVOLVEMENT where they CONNECT with the customers to understand their need and set expectations on the milestones and delivery. They work on managing the dependencies on the product which might extend to different teams, this requires a lot of effort because if any of the dependency goes unnoticed it impacts the overall release plan. 

They also work to keep the backlog stay up-to-date which ordered and prioritized requirements, this is a critical aspect as the CLIENT satisfaction is the key, they need to stay competitive in the market. Underestimating the role of the product owner or the release product owner can give a big set back to the teams and the organization, they should be given space to try out things and have them increase the collaboration with the customers and the teams.

Usually, the titles used in software development INCLUDE Program Manager, Technical Program Manager, Technical Product Manager, Product Analyst, or Product Owner. Each of them has a common SET of responsibilities, which have been defined below:

• Creates and MAINTAINS the Product Backlog
• Prioritizes and orders the Backlog as per the business value
• Supports with the bifurcation of Epics, Themes, and Features into user stories that are small enough to be completed in a single sprint.
• Delivers the VISION and Goals at the beginning of every Release and Sprint.
• Epitomizes the customer, interfaces and involves the client.
• Takes part in the daily Scrums, Sprint Planning Meetings, and Sprint Reviews and Retrospectives and another sync up meetings with the team.
• Reviews the product development at the finish of every iteration
• This role is the FACE of the Team to the outside world and should make sure that all methods of communications are open and that projects have the right amount of support required to succeed.
• Dismisses a Sprint if it is found that a severe change in course is required

As defined in Scrum, the scrum team comprises of the development team, the scrum master and the product owner, so yes, the product owner is a CRUCIAL part of the scrum team. The product attends the scrum ceremonies with the development team and stays available throughout the sprint to assist the team members in terms of requirements. The product owner is part of the sprint planning to ensure the team commits the right work and also which adds value to the product. Throughout the sprint, the product owner may or may not join the daily scrum but will be there to assist.

During the sprint demo, the product owner has to be there to accept/reject the work done during the sprint and also to provide feedback on the deliverables. The team ALONG with the product owner also sits together for the BACKLOG grooming where they brainstorm on the requirements and make it ready to be pulled up for commitment in the upcoming sprints. It is the product owner who acts as a bridge between the delivery teams and the client hence, it is an important ROLE in the scrum team. Though this role might not be involved in the technical part they take care of the functional aspect.

When the backlog is too big to be taken care of by a single product owner, there is a need for adding a PERSON who can take care of the bigger picture. Hence the role of a release product owner comes up. For EXAMPLE, the team product owner works with the DEVELOPMENT team for feature delivery and in turn, the release product owner will work to formalize the release of those feature to the market. 

The feature product owner ensures the feature is well understood by the team and they also make sure, it GETS delivered on time if there are no impediments. There can several features the team can be working on. The release product owner takes care at the higher level to consolidate the feature delivery through a release, they set the release dates, which can GO from a month to six month time. The feature PO is more focused towards the team and collaborates with the delivery teams whereas the Release product Owner interacts with the team of product owners.

The Product Owners are accountable to everyone involved in the product. They are accountable to the customers for quality product delivery, they have to MAKE sure the requirements are translated well and there is a mutual understanding of the deliverables. The clients LOOK up to the product owners for their requested WORK and the feedback loops to be taken care of by the product owners. In the same way, the product owners are accountable to the delivery team to make sure they have the right set of requirements to start their work with. 

Along with this, they are accountable for the milestones and the roadmap so that everyone talks the same language. They are even accountable to the management because of it the management who are dealing in terms of finances. The product owner is even accountable to their product backlog, to make it healthy! A lot goes into the accountability of the product owner, it’s like 360-degree accountability that they have performed. Whatever work the DEVELOPMENT team takes up, it is the accountability of the product owner and even making sure the team DEVELOPS the right thing.

According to Roman Pichler, the ultimate responsibility of a product owner is to ensure that the product creates value for its customers and users, as well as for the COMPANY. “Think of the product owner as of the person who champions the product, who facilitates the product decisions, and who has the final say about the product,” he says. “This includes if and how feedback is actioned, and which features are released.”

The role and responsibilities of a Product Owner are too deep so as to make sure he/she understands the core of the product and too wide that collaboration is done at 360-degree level, being a LIAISON and face of the user. Defining the vision - The Product Owner has the responsibility of creating a vision so that the development team clearly visualize the expected outcome by the user. Managing the product BACKLOG - The most essential responsibility in a role a Product Owner is managing the product backlog. Today’s market is really dynamic, every customer wants to stay at the top of the new features being introduced. Even the items in the product backlog might REQUIRE some movements DUE to changing priorities. Prioritizing needs - Making choices about the priority of product backlog items in order to deliver a maximum outcome. Anticipating client needs and acting as primary liaison.

Product Owner role is much wider in its scope and comes with a LOT more responsibility including researching market trends to fill GAPS with a new product. A product owner is responsible for a particular product and works to grow it RIGHT from its inception stage to maturity with a vision. A business analyst, on the other hand, would work on parallel lines as a product owner, but, would be limited by the scope of the work.

Usually, a business analyst would be responsible for a particular section of the product and would work towards its requirements or coming up with ideas to IMPROVE or innovate the process pertaining to its scope. Both PO and BA have many similarities in terms of ATTRIBUTES such as strong relationship skills, ability to think outside the box and being clear on the expectations of the work. On the other hand, the Project Manager is the person who must ensure that the scope of a project is delivered against budget and timeframes agreed. This requires the Project Manager to create plans, negotiate budgets, resources, and track progress.

A product owner is a role in a product development TEAM or a Scrum team who is responsible for the product backlog, making sure that it is up-to-date in TERMS of priorities and has the ITEMS which translate back to the vision. The Product Owner represents the business or user and is accountable for collaborating with the consumer to define what features will be in the product release. 

The Product Owner works with the stakeholders to get the right requirements, right in the sense, help the USERS to devise the requirements which they might not see or comprehend at that point. This not only improves the relationship with our customers but also helps to build up the trust. And at the other end, the Product Owner helps the delivery team/development team understand the vision and the requirements. Hence, this role is kind of a bridge between the two ends, holding tight the two corners and EFFECTIVELY enhancing the smooth communication. This role is really critical as it handshakes at both the ends – the development team and the stakeholders.

The sprint planning meeting is divided into two parts – committing the sprint items and creating the sprint backlog as per the capacity. During the first half of the meeting, the product owner should actively engage with the team to get the right stories being committed as per the market PRIORITY. The product owner can answer any open query the team has and can also talk about the expectations on the delivery. 

This role can also help the team in providing optimum ESTIMATES by clearing out any doubts. During the second half of the meeting where the team is creating tasks, the product owner might or might not attend as per the situation. If the team has all the queries resolved and they understand the priority, in this case, the product owner can STEP out and let the team create their tasks. But if there are few points for contention or the team feels they won’t be able to meet the goals, the product owner should be there to LISTEN. Ideally, the sprint planning should be attended by the SCRUM team which is – the Product Owner, Scrum Master, and the development team. Hence, everyone should be there to make it a success.

The Product Owner cannot be the Scrum Master for the delivery team. Both the Scrum Master and Product Owner are a full-time job and require strenuous efforts to fulfill their responsibilities. ALSO, the TWO have conflicting goals, as a scrum master, you will always try to help the team commit the optimum number of items as per the capacity but the product owner will just focus on delivering the maximum WORK. Also, the product owner is responsible for delivery but the Scrum master is not. In a case where a product owner plays a scrum master role, the scrum values and agile practices will take a BACK seat. The team becomes more pressurized to deliver the backlog items. The scrum master role is more on the process side and the product owner is TOWARDS the business end, mixing both the roles misbalances the transformation journey.

Anyone from the team can add items to the backlog, there is no set rule for any role to add to the backlog. During the course of development, the team can find some REQUIREMENTS which were earlier not identified, they have the liberty to add that item to the backlog. SOMETIMES, the teams might IDENTIFY some stories to improve the coverage or the quality, which is a good practice to follow. Keeping this addition to the backlog OPEN for everyone in the teams ensures that we don’t miss the requirements even if it is low on the priority list. 

Though anyone in the team can add items to the backlog it is only the product owner who is responsible to prioritize the backlog and also the one who determines what happens to the product backlog item. In the grooming meeting, the team sits together with the product owner and goes through the backlog. Nowadays, the teams use online tools to help and create the backlog, this not only helps to work across the distributed teams but also helps in keeping things together. The sole intent of creating the backlog is to CAPTURE all the requirements at one place.

A scrum team is a closed GROUP consisting of the Scrum Master, the Product Owner, and the team. All three entities in the scrum team are aligned towards a single goal. In the scrum team, the scrum master will make sure that the team is focused and will PROTECT the sprint from outer interferences. On the other HAND, the product owner will align the prioritized requirements, so that the team has a lined up stories to work on. And the third entity in the Scrum Team is the development team who is focused on the delivery of the value to the stakeholder. 

The development team takes up the ‘actual work’ in terms of coding, testing, etc. As per the scrum.org “Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.” The development TEAMS are self-organizing and cross-functional, no one directs the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. Specific Development Team members may have specific skills and areas of focus, but accountability lies to the Development Team as a WHOLE.

The team targets a pace of work that can be sustained for a long time or indefinitely. The team has to come on an agreement on how can they give to make sure that is balancing the overall structure. The term "sustainable pace", more general, was proposed by Kent Beck himself in replacement of the original "40 hour week" denomination for this Extreme Programming practice. In the first edition of “Extreme Programming EXPLAINED,” 

Kent Beck suggested working no more than 40 hours per week and never working overtime a second week in a row. FINALLY, one of the principles behind the Agile Manifesto was dedicated to "Sustainable Pace", which can be REGARDED as the most widely accepted definition: “Agile processes promote sustainable development. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

As per Sustainable pace – “Sustainable Pace is not about taking it easy and GOING slow. It's just the opposite, you should expend energy vigorously, and regain strength by resting. In the long run, make sure you invest your energy wisely and set your priorities taking into account the FINDINGS of happiness research.”

In scrum, we divide our work into iterations or cycles which are called sprints. The output of the sprint should add some value to the customer. For every sprint, we talk about time-boxing, which means it will have a start date and an end date. This timeboxing ALLOWS the customer to KNOW when they can expect the output from the TEAMS, ALSO the team knows how much they can commit so as to deliver a quality item to the client. 

Time-boxing also allows the team to focus on the value, whatever they pull as commitment is expected to be the highest priority item from the backlog which will add the highest value. Protecting a sprint means, the scrum master will make sure that the team does not commit more than their capacity, else, they won’t be able to complete the work in time. Protecting a sprint also refers to ensuring the stakeholders are not over-doing the participation in the daily activities, as it impacts the team’s focus. The team can set some ground rules or can have working agreements to make sure they strike a balance in the scrum ceremonies. And LASTLY, protection is also in terms of shielding from outside interferences.

The essential trait to win the scrum methodology is the continuous communication between the PRODUCT owner and the development team. They both need to collaborate at every step in the development to make sure the team is delivery what is expected and there are no SURPRISES at the end of the sprint. The product owner helps the team to look at the bigger picture, this role helps the team to understand the ‘Why’ of the product. During the sprint, the Product Owner helps the team in letting them know the priority so that in the sprint PLANNING they commit as the priority. 

During the course of the sprint, the team touches base with the product owner as and when they feel, they can demo something to get the early feedback rather than waiting till the end of the sprint. Along with this, the team also SITS with the product owner to groom the stories for the upcoming sprint so that they can refine and add the required details to the story and make it in a ready state to be pulled. The constant collaboration between these two helps in early resolution of dependencies or blockers and also reduces the chances of developing something which is not in the scope.

“Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.” – Scrum Inc

Velocity is a simple but powerful method for accurately measuring the rate at which the scrum development teams consistently deliver business value. Velocity is measured in the same units as feature estimates, whether this is STORY points, days, ideal days, or hours that the Scrum team delivers - all of which are considered acceptable. It is a metric which can predict how much work a team can complete in sprint TIME. 

Velocity in AGILE is the total number of points delivered in a sprint. For example, if a team COMMITS 30 points worth of stories in a sprint and by the end, they are able to deliver only 25 points then their velocity will be 25 points and not 30 points. Hence, velocity is the total points delivered and NOT the total points committed. The velocity helps the teams to predict the amount of work they can commit as a team, it also helps when we do our product increment planning in a SCALED Agile Framework.

Early and frequent delivery not only helps the team but also the customers. When we start working in iterations, there is an increment that gets added to the product, this increment is always (most of the cases) the highest priority item as expected by the customers. So, every time the customer gets the FINISHED work which they have been seeking as critical or something which was HIGHLY desired. 

Short iterations also give the customers the time they need to shift the priorities and align the requirements as per the market needs. On the contrary, the team also gets positive notes while working with software development in short cycles, which is early feedback. They get the feedback as and when they reach out to the customers with some finished items. Sometimes, during the demo the customers get to see what exactly has come out of the requirements shared by them, accordingly, they tweak and provide feedback which is then converted into a story and taken up by the teams. The early and frequent release also ensures that the scope of change will be small as compared to releasing something big. Here, every release (“iteration”) has a SPECIFICATION, development and testing phase. This means that every couple of weeks the software is fully usable, ALTHOUGH it may have very few features at the start.

The term technical debt was coined by Ward Cunningham and mentioned that some problems with code are like financial debt. As per Ward “With borrowed money, you can do something sooner than you might otherwise, but until you pay back that money you will pay interest”. Technical Debt is something where you are required to do refactoring or IMPROVEMENT related to the source code and its architecture. 

Factors adding up to technical debts cab be issues related to architecture, structure, duplication, TEST coverage, comments and documentation, potential bugs, complexity, code smells, coding practices and style. All these types of issues incur technical debt because they have a negative impact on productivity. Any compromise with the quality during the development lifecycle leads to technical debts, the software becomes fragile and expensive to extend and MAINTAIN. With the evolution of agile, we have witnessed a gradual decrease in the AMOUNT of technical debt and this was feasible because now we follow SHORTER cycles and frequent software updates require high quality, hence, the chances of piled up issues lower.

As per Atlassian “Technical debt is the difference between what was promised and what was actually delivered. Preventing technical debt is what allows development to be agile in the long run.”

The Product Owner has to understand that planning is adaptive, iterative, and collaborative which means, planning takes place at DIFFERENT levels in Scrum: 

Product, release, sprint, and day. Each level has some output which gets as an input for the next level. When we talk of planning in Scrum, it is more dynamic and change as more information about the customer needs and the product being DEVELOPED becomes AVAILABLE. The product gets build over every iteration, at the end of every sprint, there is an increment which gets ADDED to the product. The team plans for each iteration in a release with the collaboration of the product owner and the stakeholders. 

The release planning activities are carried out by the Scrum team often with the help of stakeholders, for instance, in the sprint review meeting, the team presents the backlog they have worked UPON and take the acceptance from the product owner. If there is any feedback on the items, it will be added in the product backlog and later would be prioritized by the product owner. The product owner ensures that the necessary release management activities take place. It is more of a collaboration among the product owner and the teams which results in the success of the product.

The main goal of release management is creating value to the customer. The deployment of releases into production and the establishment of EFFECTIVE USE of the service are the goals of release and deployment management process. To meet this requirement, they create a clear and comprehensive release and deployment management plan. This helps the customer and the teams to align their activities, the release management team chalks out the dates which is then targeted by the teams. 

The release management team is also involved in BUILDING, installing, testing and deploying release packages efficiently and successfully as PER the schedule. During all this, the release management team also makes sure that there is a minimal unpredicted IMPACT on the production services and above all, they ensure that the customer or the users are satisfied. The definitive goal of service management is meeting and even exceeding customer expectations and ensuring customer satisfaction in service delivery.

The Product Backlog is the master list of all functionality desired in the product in a prioritized order. Backlog prioritization is required to organize the product backlog items (user story/Defects/Spike etc) to make the sequence of its development and deployment. Prioritization leads the team’s work by concentrating the team on the most important items. It also freezes the backlog contents gradually. 

The product backlog items are detailed according to their priority. This constructs FLEXIBILITY into the process and allows deferring decisions about the lower-priority items, BUYING the Scrum team more time to assess options, COLLECT feedback from customers, and obtain more knowledge. This eventually results in BETTER results and a better product. Few of the business benefits of prioritization includes – Faster return of investment, better management of dependencies, minimizing risks and focus on value-driven development. Prioritization not only helps the business but also the teams – They can do EFFECTIVE grooming by saving the time of selection, better visibility to pick up stories within the current scope. The team can pick up the first few items from the prioritized list to discuss and work upon, in this way a lot of confusion is eased out on what needs to be worked upon.

The backlog grooming is intended for making sure that the team has the backlog which is relevant, detailed and estimated to a degree appropriate with their priority. In the backlog grooming meeting, the scrum team sits TOGETHER to discuss the items from the product backlog and this meeting is done on a REGULAR basis to keep the backlog healthy and up-to-date. 

They pull the items as per the priority order and refine them with rigorous discussion and brainstorming. They even TALK about the blockers that might come up in their way and also the dependencies, whether it is upstream or downstream. In the backlog grooming the team takes up an item from the backlog and discuss how they can work upon it, they even talk about the ways of IMPLEMENTATION. This meeting gives the team the TIME they need to understand new stories before estimating and working additionally providing time to optimize the design. It also helps in streamlining the planning meeting by saving the hours the team would have spent. By devoting time to backlog upkeep, the team safeguards that this preliminary planning occurs prior to the sprint planning meeting.

To start with any project, there is a need to have a backlog, it might not be perfect but at LEAST it provides a starting point for the teams. There are challenges if we don’t have a proper backlog, which can be, backlog consisting of very BIG items or sometimes the items do not DEFINE the exact deliverable and miss on the details. Hence, there is a need to keep it healthy,  so that it can be used by the teams to openly SEE what is next, what it can be worked upon, and what they have to plan for the future. 

A healthy backlog has 1–2 sprints of work ready to go for the team to work on which should include tech debt, bugs, and new feature work. The backlog should be VISIBLE to all the team members and everyone in the team should be encouraged to contribute so that nothing gets missed, like, new additions the team feels can add value to the client or any tools the team wants to replace to increase productivity and capability. Most importantly, a healthy product backlog is regularly ordered and prioritized. The product owner has to keep the pile of items in a ready state which can be defined under the definition of ready.

When the agile team works on the product BACKLOG, they break it down into chunks and align them into a roadmap for the delivery, during this process, they also estimate the product backlog which gives them the visibility on its completion, the functional approach, and complexity. Estimates tell at the high level of what it takes to deliver the item. Commitment, on the other hand, is the promise from a team assuring the delivery of items taken in a sprint or in a release. During the sprint planning meeting, the team pulls in some items as per the collective capacity and makes a commitment to the product owner or the stakeholders for its delivery in a time-boxed manner. 

Both estimating and committing are important activities in the scrum but they serve totally different purposes. Estimates are never a commitment from the team. An estimate is our best guess for what can be achieved and by when. One should always REMEMBER - Committing does not guarantee the delivery of items, there might be situations where the team gets STUCK because of some very VALID and reasonable IMPEDIMENT. There are several ways a team can estimate the backlog.

Estimation plays an important role when we talk about the product backlog. Estimating is about creating a SHARED understanding of the requirements, and a shared understanding of the SOLUTION. When teams have problems estimating, it’s almost never an estimating problem, it’s a shared understanding problem. Estimation can be done at two levels:

• Product Backlog level – Estimation at the product backlog level helps the team to predict much can they DELIVER in said time, it can be a release of three months or six months or as PER the product need. It also helps the product owner in making prioritization decisions. Another purpose to estimate items on the product backlog is that team members become more well-informed about the detail by thinking about it enough to estimate it.
• Sprint backlog level – Estimating at the sprint backlog level helps the teams to understand how much work they can pull into a sprint. The estimates at the sprint level are more precise which increases the possibility of the team completing all they say they will. In addition to it, this also helps the team to better synchronize their work.

When the team estimates at the product backlog level, it gives a rough or a high-level estimate, this GETS further refined when they estimate at the sprint level.

Vision is a sort of a goal you see for your ORGANIZATION, the product or even for yourself. “Vision is knowing who you are, where you’re GOING and what will guide your journey.”– Ken Blanchard and Jesse Stoner. Thus, there are three elements which CONSTITUTE a vision on a BROADER level, the purpose, the picture, and the values. Connecting the vision to our topic today, we will talk specifically about the product vision. For any product, it’s really important to understand why we are building it, what purpose will it serve to the customer or the client. 

Next comes the picture where we see how the end result should look like and lastly what value will it deliver. The vision statement can be just a few lines and it is not going to be very elaborative or prescriptive. To achieve this vision, a ROADMAP is created, it is a powerful means to define how a product is likely to grow, to align the stakeholders, and to procure a budget for developing the product and it is also a visual summary that maps out the vision and direction of the product offering over time. It outlines goals, milestones, and deliverables for a product in development.

It’s true that SCRUM doesn’t define any project manager or agile product manager role, it only mentions three roles – development TEAM, scrum master and the product owner. Each of them has their own boundaries and responsibilities. But, even before the delivery team starts working on the product, there is a lot to do like, team formation, procurement, risk MANAGEMENT, etc. these are not mentioned in any of the three roles defined. So yes, even in agile development, we do have a project manager who takes care of all these things and ensures SMOOTH startup of the teams. Even scaledagileframework.com talks about the EVOLVING role of managers in Lean-Agile development. Like the project manager, the agile product manager role also exists, it is the same as the usual product owner role, and it is just how you want to address it. The role and responsibilities are the same because it’s just another name for a product owner.

A Release Burndown Chart is one of the information radiators for an agile project TEAM and is a way for the team to clearly see what is happening and how progress is being made during each sprint. The release burndown chart has SPRINTS or TIMELINE on the X-axis and the story points on the Y-axis. Just by the glance of the chart, you can tell exactly how the release is going. It captures how much scope has been increased during the course of a release, it also gives us the insight into the stories getting acceptance on time from the PO or the stakeholders.  With the help of this chart, we can even identify if there are any risks to the delivery in the said amount of time. It is majorly used by the product team, management and sometimes the stakeholders to assess the delivery of the release. It is an important chart when we work with business OWNERS as it also gives the VIEW of items which might creep out of the boundaries.

The product backlog is owned by the product OWNER, it is one of the roles in a scrum TEAM and is aligned completely to the product. Per scrum guidelines, the product owner is responsible for maintaining the product backlog. But that doesn't mean Product Owner is only the INPUT source for the product backlog.

Any stakeholders (Business analyst/Tech architect/software architect/tester/developer/customer) in the organization/project can contribute to the product catalog. But Product owner has the ultimate responsibility for prioritizing them (with or without Development Team). It is the responsibility of the product owner to capture and add anything and everything into the backlog. Also, the product owner will make sure that the items in the backlog reflect the prioritization as the market needs. The item delivering the highest value should be at the top. There are several ways a product owner can USE to prioritize the backlog such as – Ranking, Moscow, and Hundred DOLLAR method, etc., the goal is to keep the backlog healthy and prioritized. You can even say that the product owner is the mini CEO for his own area.

The product backlog consists of the wide variety of items such as – new requirements, enhancements, bug fixes, refactoring stories, etc. but to MAKE sure the items are in a STATE for a team to commit is really important. To elaborate more, the items which the team commit in a sprint should meet a few criteria to make sure it has everything required to work upon it.

The definition of Ready is an agreement between the team and the product owner where the backlog items have to pass through a few agreed points to mark it as ready. For EXAMPLE, Definition of Ready for a story will have USER Story defined, User Story dependencies identified, User Story sized by the delivery team, performance criteria identified, no open questions, the team has a good idea what it will mean to Demo the User Story.

In the same way, we can have the definition of ready for the features as well. Although, the components might differ from product to product. This shared definition then allows the team to discard the stories that don’t have clearly defined ACCEPTANCE criteria. It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting.

All the REQUIREMENTS GENERATED from a customer needs are stored a Product Backlog. Whenever a requirement is received, it is first placed in the product backlog, the business owner or the product owner can then prioritize the items as per the market and customers’ needs. It is a kind of a bucket which accumulates all the necessary items to deliver a complete product. There are several ways to create a product backlog, some use manual charts, OTHERS use excel or the tools available supporting Agile such as Rally, Version 1, etc. One should always remember, the product backlog is not a substitute for a requirements specification.   Any FEEDBACK from the customer during the demo or and the grooming call should be captured and logged in the product backlog. This way it makes sure NOTHING gets missed, even if it is a low priority item.

Before TALKING about the traditional requirements, let’s understand what a USER STORY is. Nowadays, if you are in an agile organization, everyone would be talking in terms of user stories.

User stories are short descriptions of functionality told from the user’s perspective where the focus is on why and how. The user story concentrates on the EXPERIENCE — what the person USING the product wants to be able to do. A traditional requirement concentrates on functionality — what the product should do, it talks more in terms of the ability of a product. Traditional requirements documents go into excessive detail on how an area of software should be designed. They typically provide instructions to the software team on how to build it. Requirements documents often contain things like executive summaries, scope, risks, and more. In contrast to the traditional requirements, a user story is a much simple with acceptance criteria to define the completion. Also, a user story talks about what exactly is the user’s need at the very lowest level of implementation.

SCRUM is an iterative and incremental way of DELIVERING value to the customers in a time-boxed manner. It is a simple framework for effective team collaboration on complex products. Jeff Sutherland, together with Ken Schwaber created Scrum as a formal process at OOPSLA'95. Scrum is a very lightweight MODEL and easy to understand the model for any team but though it is easy to understand it is really difficult to master. 

The foundation of scrum lies in its values which are Courage, Focus, Commitment, Respect, and Openness, any team opting for scrum should be open to adopting these values to make the team successful. As mentioned earlier, scrum is really lightweight and it does not prescribe much of hierarchy or embedded roles, it just talks about three(3) basic roles – The Product Owner, The Scrum Master, and the Scrum Team, that it! Scrum Teams are self-organizing and cross-functional. Self-organizing teams select how best to achieve their work, rather than being directed by others outside the team. Cross-functional teams have all capabilities desirable to achieve the work without depending on others not part of the team. As per the survey by Version 1, scrum is the most widely used framework across the globe, isn’t it interesting!!

A ‘product’ is a tangible/non-tangible item created to produce SPECIFIC value for a GROUP of customers and to the organization that provides it. A product can be anything, it can even be an idea. From that, a spoon would be a product. The Facebook application would be a product. Agile consulting services would be a product. A painting would be a product. A product can be SOMETHING physical (the spoon). It can be a digital product (Facebook application, an e-book or online videos). It also can be a service (consulting). As stated by Mike Cohn – “Products Can Be Defined Recursively” which MEANS a product can EXIST within another product. Another important thing to note is, the product should deliver some value to the customer. Even the smallest entities in the product (sub-product) should be beneficial to the market.

EARLY design in Agile means CREATING just enough design up front to give a good FOUNDATION to start from and helps to mitigate risk, WITHOUT wasting UNNECESSARILY time. As the product evolves, the design emerges.

The role of PO and SM has some overlaps and a good coordination between the two is key to a successful scrum team. Scrum Master facilitates activities like backlog grooming, Scrum master communicates the outcome of sprint RETROSPECTIVE to PRODUCT owner so that next sprint could be IMPROVED. Since Scrum master works closely with scrum team, he also helps the product owner to overcome any teaming CHALLENGE within development team. In general, the role of SM and PO complements each other.

Agile manifesto uses the TERM ‘Over’, which means a higher preference to working software, it does not say that we do not need any DOCUMENTATION in agile. This means ONE should do the necessary documentation to SUPPORT the development and use of the product. An open discussion explaining the development team about it with involvement of Scrum master would HELP.

There cannot be a fix answer to this question. What interviewee will be looking for is that the product OWNER should talk about DESIGN, functionality and usefulness of the product and should clearly articulate it.  Also, the INTERVIEWER will give some point on the creativity of the product being picked. 

Since a product OWNER is part of estimation meeting, for larger stories, he may try to explain it to the development team to ensure that they have UNDERSTOOD it correctly and have sliced it PROPERLY. If STILL he FINDS a challenge, he could further discuss it with Scrum master. The SM can coach the team further.