A Product Owner must be an expert in the business domain and industry. To understand customer requirements better and translate them into product requirements, a Product Owner must be well-versed in business logic as well as the technical capabilities of the product. It is a diverse role that requires a mix of several skills and experience for high performance.

If the Product Owner has this authority, he can respond to the changing needs of the customer and the marketplace. If not, he is blocked from being effective and may need approval on all Product Backlog Item decisions which causes a waste of time, by the Product Owner, and waste in the effort, by the Scrum Team.

The product owner is a technical role. You can’t become a great PO if you don’t know the ins and outs of development, design, agile framework, software development, scrum approach, and IT infrastructure. Technical skill is defined as a specialized skill that is used to perform a specific task such as programming and software development. The agile product owner must be technically sound because backlog management and prioritization are technical tasks. It can’t be done effectively if the PO doesn’t understand the development and design processes and has no knowledge of how software development works.

Product Owner’s need is almost there on all the events except Daily Scrum because Daily Scrum is a time-boxed event for the Development Team to inspect and adapt daily. When a Product Owner is not available during the Sprint, it is one of the great impediments. It will certainly affect the ability of the Development Team to come up with a “done” product increment. If there is no Product Increment at the end of the Sprint, then the Sprint Goal cannot be reached.

The Agile definition of done is a collection of criteria that must be completed for a project to be considered “done.” It is essentially a checklist used by Scrum teams to create a shared understanding of what is required to make a product releasable.

To fully understand the definition of done in the context of Scrum, we must first outline two of the key elements in Agile project management:

• Product backlog item: This is a specific improvement that is made to a product. Items can include bug fixes, user stories, and specifications.
• Product increment: This is what is produced at the end of a short development period or sprint. It combines all the product backlog items completed during this sprint.

In specific terms, the Scrum definition of done is a list of conditions that must be met to successfully mark a product increment as complete.

Attendance is not limited to the Scrum Team. When it’s needed, for example, for refinement, the Scrum Team can invite SMEs to provide additional information. This could also include users, the client, or any other stakeholder. This makes the event more engaging, as well as shows you value the opinion of others.

Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Throughout a good agile project, you should expect to have user stories written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

Trust is the bedrock of self-organizing agile teams. Trust allows agile teams to communicate quickly and respond rapidly to changes as they emerge. Without sufficient trust, team members can waste effort and energy hoarding information, forming cliques, dodging blame, and covering their tracks. A climate of trust provides the foundation for effective team processes, adaptability, and high performance.

The best way for a team to estimate its product backlog items is in story points and its sprint backlog tasks in hours.

This works well because story points are a more abstract measure that individuals with different strengths can agree on. Just as you and I can agree on the length of the measure “one foot,” even though our individual feet are most likely different lengths, so can agile team members of different skills agree that this user story will take twice as long to do as that user story.

Story points don’t work, though, at the sprint level. During sprint planning, remember the goal is for a team to determine how much work to bring into the sprint. That’s hard with abstract units like story points. It’s far easier with hours.