Dual Roles Of A Product Owner – The Stakeholders And The Team, How To Balance Them?

A product owner has several responsibilities, and is required to focus upon certain important aspects while scrum framework is being implemented in the project:

• To think about the end users, market conditions, and the stakeholders on one hand,
• And to represent the scrum team on the other.

It is not an easy job to carry out. Quite often, the product owner may face dilemmas while carrying out the responsibilities on behalf of the stakeholders – to convince the team members to deliver successful product increments, and to act in their best interests. It can be a challenging position indeed.
 

The outward view: Users, customers, and stakeholders

The first and the foremost priority of the product owner is to understand the primary needs of the end users and customers. The basic purpose of having a scrum project and implementing scrum methodology in it is to develop an “acceptable” product. The end users are important for the project since they determine whether the product is going to succeed in the market, and, what the ideal product should really offer to be successful. The person may be required to conduct personal and group interviews to understand their needs in depth, and avail a clear vision as to what kind of product they really desire and expect. As is the case, many times users have their own ideas as to what the end product should typically offer in terms of features and functionalities. The product owner is forced to review their expectations and ideas at a macro level and ascertain the practical aspects pertaining to the product to be developed. If the users have varying requirements, or differing perspectives, as to what the product should consist of, it is eventually up to the product owner to decide which of the aspects discussed are really important and feasible, and which can be incorporated in the project.
 

The stakeholders are important since they invest into the project. The product owner receives the actual product related requirements from them. However, their priorities and perspective are focused more upon generating a profit out of the project, and it is up to the product owner to deliver the project – nicely wrapped up and ‘ready for sale’. The stakeholders also remunerate the efforts of the entire scrum team including the product owner. It is therefore essential that the product owner complies with their instructions and act in their direct interests.
 

The product owner has to respond to the questions put forward by the users, customers, and the stakeholders. He or she has to advise them, and maintain a vision that can best convey what is important and profitable to them. 
 

The inward view: The scrum team – scrum master and the development team

While the stakeholders and the end users are important, the development team and the scrum master too are important to the product owner since they are directly responsible for developing the project. Scrum supports collaboration, and the entire team collaborates with the product owner while scrum is implemented in the project. Needless to say, without their help, it is not possible for the product owner to deliver anything.
 

In most cases, the product owner acts as a facilitator and ensures the team is properly working at all times. He or she has to remain close to the actual development work, and be available whenever the team faces any problems or issues with the acceptance criteria linked with the user stories, and resolve the issues when they occur. The product owner has certain responsibilities towards them. Apart from being a product owner, the person also acts as their mentor, guide, and a good friend whenever his or her role so demands. 
 

Balancing the views: Switching the role as per requirement

Even though the role played by a product owner is a difficult one, it is not an impossible. One does not have to be a specially gifted person to tackle both the aspects faced while executing the project. It is essential, and very much required, to balance both the aspects and switch the roles depending upon the situations you face. Flexibility of the thought processes, ability to communicate in an effective manner, and negotiating with people can go a long way in making the work easy as a product owner. The PO is required to keep a firm eye, peruse the market conditions, and handle the stakeholders when his or her role demands. Simultaneously, keeping a humane attitude while interacting with the team members can go a long way in keeping the person popular.
 

Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which can help you in implementing scrum framework in your projects!

The Desirable Characteristics Of A Good And Effective Product Owner

The role of a product owner is very important in scrum. Besides representing the client and the stakeholders in the project, the  “PO” also has several responsibilities to fulfill with regards the scrum team and the scrum master. The role is not an easy one. The challenges faced by a PO extend far beyond the capacity of a traditional product manager. Besides being responsible for the project’s success, the PO has to carry out several other activities such as:

• Preparing the product backlog
• Defining the product backlog items
• Working out the sprint releases
• and reviewing the work carried out by the development team.

The person is also responsible for defining the acceptance criteria linked with the user stories, and accepting the work as “Done” during the sprint review meetings. Product owners are often pressed for time, and may face certain difficulties while carrying out their work.

It is worth knowing what makes an ideal product owner. Some of the most important characteristics are mentioned herein.

A visionary and a “Doer”

The individual should have the vision to imagine what the final product should be like, and communicate his or her vision to the entire scrum team. The person should also be a “Doer.” He or she should lead by example and preferably use a servant-leader role while delegating authority. The effort should be made to facilitate the scrum proceedings, rather than to issue orders and wait for the team to fulfill them. The person should be able to capture the ideas regarding the requirements as to how the development should be carried out, in what manner, and collaborate closely with the team to avail proper and useful feedback, and analyze it to make informed decisions. The PO should possess the capability to steer the project in the right direction and forecast its progress from time to time. The individual should also think as an entrepreneur and provide valuable suggestions regarding the product to the stakeholders and the investors. It is important to facilitate creativity, encourage and support new ideas and vision, motivate the team members, and feel comfortable while dealing with the changes in the product definition as and when the stakeholders apprise him or her about new product related requirements to be carried out in the functionality developed till date.

Be a leader and a great team player

While talking about the scrum framework, a good PO should be able to create a vision, articulate it, passionately own it, nurture it, and relentlessly strive to achieve the vision in real life by presenting the product to the stakeholders – exactly as they want it. It is exceedingly important to guide the team and everyone involved with the project, and be ready to make tough decisions when they are called for. Above all, the PO should encourage and promote collaboration as it is the base upon which the scrum methodology operates and delivers the results. It is not recommended for a product owner to dictate decisions and delegate authority in an autocratic manner. Moreover, even though the PO is empowered to make decisions, the person should ideally seek the team’s consensus for all scrum related activities. If possible, the team ought to be involved in the decision making too, although few product owners actually prefer to do it in real life.

A good communicator and an effective negotiator

To be a good product owner, and an effective one, the person should possess the skills necessary to negotiate successfully with the customers, end users, development and engineering teams, marketing and sales executives, service personnel, operations department, and the management. It is also important to be a good communicator and have the ability to explain complex ideas and thoughts in a simple and straightforward manner to people who are not technically sound or who are naive.

Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.

The Role Of A Product Owner

The product owner in scrum
The product owner is a very important person in scrum. He or she owns the product on behalf of the company and the stakeholders. The person is responsible for the overall success of the project, and should oversee that the product development is carried out in a proper and planned manner as per the implementation rules suggested in scrum methodology. To carry out the responsibilities in an effective manner and make proper decisions at the correct time and in the correct manner, the product owner is endowed with certain powers, and authority, and the person should utilize those powers to ensure that the project is executed in a successful and desired manner. 
 

In real life, the role of the product owner varies in accordance to the nature and requirements associated with the project. Several factors such as the ongoing market conditions, the product development life cycle and stage, and the management influence how the product owner should set up priorities in a project. The participation of the product owner is very important in the initial stages of the scrum project when the product backlog is to be created and sprint durations are to be set up. The product owner’s work profile is not an easy one, especially if the organization is new to scrum, or if the individual lacks enough experience working as a product owner. 
 

What decides the role of a product owner in real life?
The best way of knowing about what a product owner should ideally do to be considered as a “perfect” product owner is to refer to the official scrum guide and pick up hints as to what the guide suggests. It is important to know that scrum is all about adaptation and being “agile” in its implementation. When scrum is to be implemented in a project, it should be done so in a manner such that the objectives are best fulfilled in the manner desired by the stakeholders. Many a times, the product owner has to change his or her working style and adapt to:

• What the project demands in terms of responsibilities
• The goals set up by the stakeholders
• What the scrum team is capable of delivering
• What the person is capable of delivering in terms of productivity and goal achievement on a personal level

When scrum is being implemented, the product owner is expected to engage himself or herself in a proactive manner and facilitate the working as and when possible. The person is generally expected to:

• Collaborate closely with the team members on a consistent basis
• Guide and direct the scrum team
• Monitor and actively manage the product backlog
• Answer questions and provide solutions to problems and questions when they arise
• Provide appropriate and useful feedback to the stakeholders and the scrum team whenever required or demanded
• Signing off work

In simple words, the product owner takes the back seat, decides what should and should not be done, and make sure the product is shipped at the correct time.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How Scrum Can Help To Reduce The Risks In Development Projects – Find How Risk Mitigation Is Possible While Implementing Scrum

Scrum projects and risks
Every project in scrum, irrespective of its size and scale, is subjected to certain risks. The risks may be minor in nature, in which case they could be easily solved. Alternatively, they could be of larger magnitude, and would really tax the experience levels of the scrum master as well as the product owner to resolve them. Catering to risks is one of the main reasons why managements and “C” level executives opt for scrum methodology. 

Actually most people interpret risks in a negative way. It is interesting to know that risks can be negative as well as positive in nature, depending upon the outcome they result in. Risks, which result in a positive manner, are termed as “opportunities” while those that negatively affect the project are known as “threats”. In a simple language, a risk can be understood as a particular situation, unknown about what kind of result it will deliver when it is conceived, and which can result into an advantageous situation, or it could adversely affect the project working as well as the result the particular project is fundamentally supposed to deliver. Risk management is an inherent part of scrum methodology.
 

Minimizing risks (threats) using scrum methodology
While positive risks, or opportunities, are inadvertently welcomed, it is the risks, which create a negative effect in the ongoing project, or threats, which are of concern to scrum enforcers. Scrum helps to minimize risks in several ways:
 

Flexibility exhibited by scrum reduces business-environment-related risks
Unlike traditional development methodologies, scrum is highly flexible, and possesses the capability to add or modify the project related requirements at any time during the project life cycle. It helps the management to respond in a positive manner to threats as and when they arise. The management can easily cater to unforeseen circumstances when they arise. It is very easy to remove the user stories from the product backlog and replace them with new ones. The product owner can add new stories whenever required as per the wishes of the stakeholders. Moreover, if a particular set of requirements becomes obsolete or useless in terms of its functionality, it can be removed from the product backlog, and its development can be curtailed. This is not possible in a Waterfall method.
 

Constant and regular feedback reduce expectations-related risks
The entire project development is carried out in sprints. Each sprint is preceded by a daily scrum meeting. Scrum provides plenty of opportunities to avail feedback regarding exactly how much development has been successfully completed until date, and how much of it is still pending. The scrum board reflects the changes as and when they occur in real time, so the management is always kept informed about which user stories are currently being processed for development. Stakeholders can verify the work delivered at the end of the sprint, and if they are not satisfied, they hold the right to reject it. The investors are never caught off guard owing to miscommunication. They can always check up the development status and act accordingly.
 

Team ownership helps to reduce estimation related risks
The team creates proper and effective estimates making use of prior development related experience. Sprint retrospectives help to identify potential pitfalls likely to occur again in the future while sprint planning helps to include proper user stories for time bound and acceptable development. Team ownership helps to reduce estimation related risks.  
 

Increased transparency reduces non-detection risks 
Scrum advocates transparency. Everything and each activity carried out by the scrum team is made public as soon as possible. As a result, any risk, if it arises, is detected early by the concerned person, and the person is supposed to take up further course of action to remove the risk. Risks are detected and communicated early, and this leads to better risk handling as well as risk mitigation.
 

Iterative development reduces investment-related risks  
The delivery value is continuously presented when scrum is implemented. The basic advantage of scrum is that functionality is delivered in stages after the sprint is completed, which generally takes from 2 weeks to 1 month depending upon how long the sprint lasts. This is not possible in case of waterfall methods since the results are derived in the final stage of the product development cycle. It then becomes too late to respond to the development, and to introduce new changes because the entire project is completed by that time. Scrum helps to reduce investment related risks.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Means Of Communications For Collocated And Distributed Teams While Implementing Scrum

The scrum development team
The scrum team is the heart of any scrum based project. The development team is directly responsible for manufacturing the functionality linked with the particular project. The development activity is carried out by the team members during the iteration or the sprinting activity, which generally lasts for up to two weeks. It is very important for the team members to “jell” with each other, and collaborate, because it is a prerequisite while implementing scrum. The physical location of the team members plays a very important part while the sprint is carried out. In most cases, the entire development activity, and the sprint too, is carried out in a single location, or the same place – under the same roof. However, with the advent of off-shoring and using scrum for complex and extended product development, it may become necessary for the team members to remain located in different geographical locations owing to various reasons.
 

Advantages of having a collocated team
For healthy scrum implementation, high level, and frequent communications are essential between the team members as well as the scrum master while the project is underway. It is generally preferred that the team members are collocated. Collocation means all the team members share a common development location, and even similar infrastructure, during the sprint. There are several advantages of being collocated:

• Questions can get answered quickly and easily
• Problems can be fixed “on the spot” with minimal wastage of time
• Less friction is created in the interactions of the team members
• Trust is availed and rendered much quickly

Means of communications for collocated and distributed teams participating in the sprint 

It is important to communicate in an effective manner to improve collaboration. Several types of tools and methods can be used to improve the collaboration amongst team members.

Collocated teams
- Teams working in and sharing the same office.  Since the team members are located in the same premises the preferred methods of communications can be:
   o Face-to-face
   o Messaging utilities
   o Internal chat tools
- Discussions can also be facilitated using:
   o Meeting rooms
   o Scrum boards
   o Wall displays
   o Shared tables
 
Distributed teams
- Teams placed in different geographic locations.
  Some of the tools recommended for communication purposes are:
   o Video conferencing tools and hardware/software
   o Instant messaging utilities
   o Chatting utilities
   o Social media tools
   o Shared screens
   o Remote access facilities
   o Specialized scrum software which emulate the functionality offered by traditional scrum boards
 

The daily scrum meetings cannot be conducted in a traditional matter since all the team members cannot remain present in the same place owing to geographical distances. In such cases, remotely located team members should participate in the meeting using electronic and online facilities. It is important to set up a fixed meeting time so everyone included in the sprint can participate easily.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

What Is A Sprint Retrospective And How It Should Be Conducted

What is a sprint retrospective and why is it so important?

Evolution is a continuous process, and if a person studies the past, he or she can avail a much better idea about how things exist the way they do today. The rule is not so different for scrum. If one is able to study the performance of sprints which have been carried out in the past, one can possibly know about what issues and pitfalls have affected prior sprints, and in what manner. Sprint retrospectives offer an opportunity to learn from the sprints which have already been carried out, and what the management still needs to learn from them. It is one of the main reasons why retrospectives exist in scrum. At the end of each sprint, the product owner and the scrum master meet to discuss about, and analyze the sprint which has just been completed. The process enables the scrum team to better itself, and avoid the problems which have occurred in the past. The entire team as well as the project can move forward in a positive and a fruitful manner.    

The lessons learnt and the results obtained from a retrospective are very much useful for planning the next sprint. The results play an important part in the sprint planning meeting carried out just before a new sprint is initiated. Ideally, a meeting lasting for 30 to 60 minutes should be carried out immediately after the current sprint is over. The main purpose of the meeting should be to brief the team members as to how they should prepare for the retrospective to be held at a later date.

Who attends the retrospective?

It is mandatory for the product owner and the scrum master to attend the meeting. Ideally, the meeting should also be attended by the team members since the main purpose of the meeting is to learn about the mistakes occurred during the sprint, and concerns the team. If so desired, the investors and the stakeholders can also attend the meeting. However, their role should only include providing feedback and any information pertaining to the acceptance criterion if so required by the team members or the product owner. 

Conducting the retrospective

Before starting with the retrospective, ensure that each person attending the meeting is clear about what is to be discussed, and what goals are to be achieved from the meeting. It is important to convey that the purpose of the meeting is not to point fingers and accuse others for something that has gone wrong. The team should face the problem collectively and in a sporting manner.

Chart out the entire sprint on the whiteboard and indicate the user stories which have met with difficulties, or which have not been accepted as “done”. Instruct the team members to take notes as the meeting progresses, or as and when they feel it is necessary to do so.  Discuss about the actual problem which has occurred. Explain about the exact nature of the problem to the team members, and how the particular problem has affected the results desired out of the sprint. In addition, the members could also be explained about the significance of the problem from the ROI point of view. In the end when the briefing activity is over, ask the team members to submit their notes and encourage them to participate in the discussion. Ask them to contribute their opinion as to how the problem could have been avoided, and what steps should be taken to correct it.

It should not matter if the team member lacks the knowledge or the experience to contribute anything concrete or of significance during the discussions. It should also be acceptable if the particular member offers a suggestion which is wrong or unacceptable. The basic purpose of the retrospective is to learn through collaboration. There is learning involved in the process, and the team should benefit from the discussions in a positive manner. Moreover, scrum advocates active participation and invites suggestions from everyone associated with the project. It is for the product owner and the scrum master to unanimously decide which suggestions are important and should be taken up for consideration.    

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!