PO Interview - Agile Scrum Knowledge Flashcards
How do you prioritize product backlog if you were a PO
We always have limited resources to handle infinite feature requests from various stakeholders. I know there are framework to help PO to prioritize their US in the product backlog, each of them have pros and cons. I think product prioritization is at times more of an art than a science. Sometimes these following these framework exactly might not be adequate all the time. In order to remain efficient and effective, we need to take consideration in practical situation based on the project and organization.
Consideration: Nature of the business Stage of growth of company Localized vs Global product The effect of competition New features vs Tech debts
MoSCoW – Mo (Must be), S(Should be), Co(Could be), W(Won’t be)
RICE method - Reach, Impact, Confidence, Effort
Etc.
In conclusion, above are 5 practical tips which in my opinion play an important role in your decision to prioritize features to be built for the product. Always remember that the act of prioritization of features is more an act than a science, you will not only need to be able to convince the stakeholders on reason and but also appeal to their hearts to make them fully convinced.
What are the characteristics of a good product backlog item?
A good product backlog item should be DEEP – D (Detailed appropriately), E (Estimated), E (Emergent), P (Prioritized)
Do we need a PO for a DevOps team?
Yes. A DevOps team also works around a product. With automation, CI/CD, it becomes more important for DevOps team to understand business requirements and needs and then automate the delivery pipeline. The business need could not be understood correctly, and doubts answered without a Product Owner.
What are the characteristics of a good user story?
A good user story should be Independent (I), Negotiable (N), Valuable (V), Estimable (E), Small (S), Testable (T). In short – INVEST.
What is AC? Who sets it?
Acceptance Criteria is a set of accepted conditions or business rules which the user story or feature should satisfy and meet, to be accepted by the Product owner. They are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements applicable at the current stage of project integration.
The Product owner sets the acceptance criteria.
Is Definition of Done is same as Definition of Ready
Definition of Done (DoD) is a simple list of activities such as writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
Definition of Ready (DoR) is a sort of criteria or at times checklist that determine whether a story is “Ready” to be picked it for next sprint.
How does Burn Down charts help a Product Owner track the progress of a Sprint?
Burn-down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed
What are the qualities or characteristics of a good product owner?
A good product owner is someone who should be
Available and engaged with the team.
Have good knowledge or product and domain.
Good at communication.
Empowered to take decisions related to the product.
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.
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.
What is tech debt?
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.”
Who can make adjustments to the backlog?
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.
What is Agile methodology
Agile methodology is a way of organizing workflow that focuses on close engagement with customers and producing products rapidly but through small deliverables that give value to the client. The idea is that once these iterations are provided, internal stakeholders and customers can test them.
Once you’ve figured out how to make the most of the Agile mindset, you can use a specific technique, such as Scrum, to keep projects on schedule.
Agile Methodology Steps
Here the stages of the Agile software development life cycle (SDLC) sprint workflow:
Plan. The sprint starts with a sprint planning meeting, in which team members gather to plan out the components for the next round of work. Next, the product manager assigns work to the team based on a backlog of activities.
Develop. Design and develop the product in compliance with the parameters that have been accepted.
Test. Before delivery, complete rigorous testing and documenting of results.
Deliver. The Product Manager will show stakeholders and consumers the finished product or software.
Assess. Solicit input from customers and stakeholders, and compile data to be used in the following sprint.
In addition to sprint planning sessions, your team should meet daily to check in on progress, resolve any issues, and try to keep the process going ahead. Maintain your flexibility and adaptability to changes. The Agile software development life cycle’s objective is to build and deliver functioning software quickly. After all, there’s a reason why this methodology is named “Agile.”
Agile Development Team
Team Leader: This position supports the team, ensuring that it has the necessary resources for the project. This job covers project management’s soft abilities, but not the technical ones, such as planning and scheduling, which are better left to the entire team.
Team Members: This refers to developers and programmers, or in other words members in charge of developing and delivering a system.
Product Manager: The product manager represents the stakeholders. They are the one person in a team responsible for creating the product road map, making timely decisions, and ensuring stakeholders that the product is on the right path.
Stakeholder. Anyone who is a direct user, indirect user, manager of users, senior manager, or operations staff member who funds the project, support staff, or provides any one of the numerous ancillary functions.
