The Core Role And Responsibilities Of A Product Owner In Scrum

The primary role of the product owner in scrum is to actually “own” the product and function as a “decision maker” on behalf of the stakeholders and project owners. The PO is employed by the stakeholders to represent their interests while implementing scrum framework in their projects. Contrary to what most people new to scrum believe, a product owner can ‘own” a product, but is not necessarily its “owner,” in most cases.

The core job of the product owner, or rather the main responsibilities, are:

• Plan the product release and work out how to “make” the product through consistent product increment
• Ensure that the sprints are successfully completed during the project
• Shippable and “bug free” products are delivered at the end of sprints
• Ensure that the project is successfully completed

The product owner’s job is a difficult one, and a full-time one.   

 

The product owner as the core determinant of a successfully completed scrum project

It is essential to deliver the product value at all times. The scrum “mechanism” requires efficient, reliable, and accurate methods, which can help to support the product vision as envisioned by the stakeholders, and create an effective pipeline having the capability to distil the product vision into shippable, concrete, and deliverable user stories that can successfully demonstrate the tangible benefits of the product. It is the primary reason why the role of a product owner is a very important one while implementing scrum.

While the product owner participates in most scrum rituals, his or her main function, parallel to that of the scrum master, is to act as a facilitator for the entire team, and be available to the team when problems and issues arise. 

The main tasks of a product owner are:

• Envisioning the product and facilitating its development
• Creating an iterative or sprint release strategy which can incorporate the changing market conditions and product requirements
• Distilling the high-level product related requirements into developable and deliverable user stories linked with acceptance criteria
• Prioritizing the product backlog
• Communicating difficult and complex system architecture issues to the clients
• Negotiating all client-sided disputes and concerns associated with the product design, development, and user story priorities

 

Responsibilities of a product owner

The PO is mainly responsible for:

• Representing the interests of, and acting as the voice of stakeholders and customers
• Understanding project profitability and delivering high ROI
• Managing and communicating with the stakeholders
• Promoting collaboration amongst the team members
• Undertaking on-the-spot tactical decisions and ensuring that the product development cycle is not affected
• Participating in the release meetings and planning
• Writing effective user stories
• Maintaining and updating the product backlog
• Helping the team in estimating the development time for each scrum scenario
• Participating in the sprint review meetings, accepting the user stories as “Done”, and providing effectual feedback
• Monitoring the project progress and suggesting constant adjustments based upon important strategic objectives

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

Avoiding Product Backlog Pitfalls – Get The Most Out Of Scrum

The product backlog is the heart of scrum in many ways. All the technical requirements needed to develop the product are included in the form of user stories in the product backlog. It is important that the product backlog item, or the user story, should be properly defined and narrated within the backlog. A product backlog item consists of several types of information, which actually define the exact requirement to be developed by the developed team during the sprint. It is very important that the product owner, the person who defines the user stories in the product backlog, avoid certain pitfalls, which can mess up the readability of the user story, or make it ineffective for development purpose.  
 

Creating the product backlog without any prioritization 

Estimation is an integral part of scrum, and burn down charts are created to reflect the velocity at which the team is currently carrying out the daily sprints. Estimation is possible only if backlog items are prioritized with user stories.
 

Creating the headline and not adding any explanatory description
Adding a title to mention the story name alone does not suffice. The team needs more information regarding the story to be developed.
 

Using less priority levels 

The user stories should include at least three priorities – high, medium, and low. Using only two priority levels such as “urgent” and “Later” fails to give a proper idea to the team as to how important the story is from the development point of view.
 

Committing the release date without prior communication
The team should be initially consulted and a release date worked out before apprising the stakeholders about the date.
 

Creating tasks instead of user stories
During the second half of the sprint planning meeting, the team segregates the user stories into individual tasks. The product owner should not define individual tasks in lieu of user stories in the backlog.
 

Long running sprints
The sprint should ideally last up to two weeks. If the cost effectiveness of product development is to be maintained, the sprint should be properly decided. It should not be too long so that feedback is availed after long intervals, and it should not be too short so that the team does not have enough time to develop the tasks. Both the aspects should be properly balanced.
 

Preparing a limited number of user stories
When the scrum project is planned, the product owner should create the entire product backlog. Creating a few stories to “start” the scrum process defeats the very purpose of implementing scrum, since proper estimation cannot be carried out, and velocity too cannot be determined in an effective manner.
 

Meeting only once a week
The product owner should be available as and when required by the team members and the scrum master. Meeting only once a week can prevent the team from proceeding with the development in case any problems are encountered during the sprint or additional information is required to understand the user story.
 

Answering your phone during the meeting
Perhaps the most irritating aspect is answering cell phones while a meeting is underway. It not only wastes time, but also breaks the concentration levels.
 

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

Reasons For Carrying Out The Product Backlog Grooming Activity

What is product backlog grooming?
The main objective of the backlog grooming session is to improve the product backlog and rearrange the user stories or the product backlog items in accordance to the new priorities determined by the stakeholders or the team members. Grooming sessions can also be held to verify the product backlog items whether they have the information necessary to develop the user stories in a more efficient manner. The scrum guide does not try to define what a backlog grooming session actually is because the “grooming” activity may vary from project to project. It is difficult to standardize the process so that it can suit all types of projects. The grooming session are generally held to:

• Write or rewrite the product backlog items or user stories if they are not properly stated or described
• Reschedule or re-prioritize the product backlog items based upon the recent updates provided by the stakeholders
• Segregate epics or large user stories into smaller and more manageable ones
• Re-estimate the story points linked with the user stories
• Update or add new acceptance criteria to the user stories
• Analyze the product backlog for planning purposes

 

Product Backlog Grooming In Scrum

Different reasons why the product backlog is refined
The product backlog can be rescheduled or refined for a number of reasons depending upon the changes occurring in the market conditions or new features demanded by the end users. At times, it becomes necessary to weed out less important tasks and replace them with effective ones. The product owner may decide to reprioritize the backlog if he or she feels some of the user stories need to be developed on a priority basis. Usually, the product backlog grooming activity or product refinement is carried out because of three main reasons:
 

Refinement carried out by the stakeholders
As the market conditions keep on changing over time and new competitive products are launched, it becomes necessary for the stakeholders to do away with some of the functionalities in the product which have become obsolete and are no longer needed. It is meaningless to spend time and efforts over features which are not likely to score for the product in the market, and which no longer have a selling value. The investors and stakeholders remain in touch with the ongoing market trends, what the end users require, and how the selling value of the product can be increased by introducing new set of features and functionalities while the product is being developed. The stakeholders may decide to “overhaul” the project by removing some of the features and functionalities, and replace them with new ones, which have added market and selling values.
 

Informal product backlog grooming 

One of the important objectives of carrying out the product grooming activity is that the team members too attend the grooming sessions, and it offers an opportunity for the product owner to explain the user stories to the development team. The product owner takes the opportunity to describe and explain the new set of product backlog items to the team members and answer questions regarding the business values of the user stories. It is a great way of understanding what the product eventually focuses to do when it is launched in the market and how it is supposed to behave when fully developed. Generally, the grooming sessions are succeeded by the sprint planning meetings, and the team is able to prepare in advance for the planning meetings in a more meaningful manner. Since the team members become more familiar with the exact functionality associated with the user stories, it becomes easy for them to segregate the user stories into development tasks during the second half of the sprint planning meeting.
 

Periodic refinement carried out by the team members
It is important to carry out “routine maintenance work” and keep the product backlog “in shape” so it becomes easy to plan the sprints. As the sprints progress and development is carried out during the sprinting sessions, some of the tasks are completed and new functionality is developed. At time, the functionality developed can be shared with other resources to be developed, and it is important to identify such resources so duplicate or repetitive development activity can be avoided and time can be saved. While implementing scrum methodology, the grooming session help to weed out the repetitive tasks and get the backlog back into “shape”. It also provides an opportunity to the team members to ask for clarifications and demand explanations for the stories they find it difficult to understand to the product owner. 
 

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

Rules For The Daily Scrum Meeting – What Every Member Should Do To Make The Sprint Successful

The daily scrum meeting rules
The daily standup or the daily scrum meeting is very important while implementing scrum. The purpose of the daily standup is to initiate the sprint activity for the particular day, with a little bit of discussion pertaining to what was done in the sprint the day before i.e. yesterday, and what the team plans to do on the particular day i.e. today. It is imperative for the team members to follow rules which can help to implement scrum in a successful manner. Moreover, the team members are also required to maintain a certain decorum while participating in the daily standup.
 

The important rules required to conduct a beneficial standup and implement scrum in a healthy manner can be briefly summarized:
 

1. Held in the same place

Ideally, the daily scrum should be held in the same place, and at the same time every day. The best time to hold the meeting is in the morning, before the development team initiates the actual daily sprint. The potential of the team can be best tapped when members are fresh, and open to ideas. 

2. Should be time boxed

The meeting should be time boxed and not extend beyond the stipulated 15 minutes allotted for it.

3. Encourage active participation

The scrum master should encourage active participation and ensure the members are collaborating during the meeting, as well as during the sprint.

4. Attend the daily standup

All team members, including the product owner and the scrum master should ideally attend the daily standup. In case of a distributed team, the remotely working team members should participate using online media and tools .

5. Maintain timings and must be prompt

The members attending the meeting should maintain timings and must be prompt. They should be mentally prepared with their brief presentations and what questions they need to ask, if required, during the meeting.

6. Each member gets a chance to talk and discuss

The scrum master should ensure each member gets a chance to talk and discuss without any inhibitions. Irrespective of the process you follow about which member should speak first, each individual should disclose what work was done in the prior sprint, and what he or she plans to do on that day.

7. Three important questions

The three important questions:

• What activity was done the day before?
• What activity is planned for today?
• Are there any issues or problems which impede the sprint process?

Should be discussed in the meeting by each development team member participating in the daily sprint.

8. Should refrain from asking questions other than those mentioned

The team members should refrain from asking questions other than those mentioned in point 7. The discussion should not include topics pertaining to designing, trouble shooting, fixing bugs, project analysis, etc.
 

9. Not indulge in gossip

Team members should not indulge in gossip or carry out any other discussion not pertaining to the daily scrum.
 

10. Only one individual speaks at a time

When the meeting is being conducted, only one individual speaks at a time. All other members should listen carefully, and make notes if required.
 

11. Address the team as a whole

The member should address the team as a whole, and not just focus or concentrate upon the scrum master while providing the feedback.
 

12. Query or problem is solved as soon as possible

During the meeting, if any team member requires help or guidance regarding a particular point or problem faced by the individual, the scrum master should ensure that the query or problem is solved as soon as possible.
 

13. Stakeholders should remain quiet and not intervene

Non-team members and the stakeholders can attend the meeting if they desire to do so, but they should remain quiet and not intervene during the meeting. They should not indulge in any activity which can distract the team members from carrying out the meeting in a proper manner.
 

14. Provide ample of room

Non-team members should provide ample of room to the development team so they have enough space to conduct the meeting, and make notes.
 

15. Scrum master holds the right

The scrum master holds the right to prevent any non-team member from attending the meeting if he or she deems fit to do so.
 

16. Any member not supporting the rules should be asked to leave

Any member, team or otherwise, not supporting the rules and regulations can be asked to leave the meeting and the vicinity by the scrum master.
 

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

Conducting The Daily Scrum Meeting Or The “Daily Stand Up”

The daily scrum or standup meeting
One of the primary responsibilities of the scrum master is to hold the daily scrum meeting, or the “daily stand up”, as it is commonly referred to by scrum professionals. The person is required to get the product owner and the team members together for the meeting. The objective is to avail information pertaining to three important aspects of the daily scrum:

• Which tasks have been completed in the sprint carried out the day before, or yesterday?
• What tasks are to be taken up for development for the particular day, or today?
• Did any team member face any hurdles or impediments during the sprint? If so, what were they?

Duration of the daily standup
The daily scrum meeting is time boxed to last for a maximum of 15 minutes, and should not extend this period.

Purpose of the daily scrum
The main purpose of the standup is not to resolve issues or provide solutions to problems. The aim is to apprise the team members regarding the current status of the project, and ensure they collaborate and contribute jointly as a team during the development activity. If any team member faces a problem, and it is mentioned during the daily standup, it is the scrum master’s responsibility to ensure that the issue is resolved at the earliest. The solutions to such problems are provided by the scrum master and the product owner.
 

Holding stand-ups for non-collocated or distributed teams
One of the major concerns, and also a probable problem at times, for the scrum master is to hold the daily standup when teams are not located in the same office or geographical area. Many companies now use and implement scrum methodology, and in certain cases, the entire development team may not be located in the same place. With off-shoring activities becoming popular by the day, soon it would be common scenario to hold meetings with team members residing in different states and even different countries. Scrum advocates that the daily scrum should include all the team members. In fact, the term “scrum” is akin to the scrum huddle often practiced in rugby, or “rugger”. With large distances separating the team members, it may not be possible to hold a daily scrum in which all team members can be physically present.
 

A possible way out is to use electronic media and facilities to decrease the geographical distances.   Team members can use Skype and videoconferencing tools to participate online in the meeting. The scrum master has to instruct every remotely located team member to log on at a particular time when the daily scrum is to be held, and explain that the members should make sure the hardware and software tools are properly functional at the time of the meeting.
 

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

Why Sprint Planning Meetings Are Important While Implementing Scrum Methodology

Sprint planning is perhaps one of the most important aspects of implementing scrum methodology. It offers an opportunity to validate the product backlog and take up user stories for the sprint backlog – the list of requirements taken up by the team members for development purpose during the sprint activity. Sprint planning involves a team effort. The product owner carries out sprint planning with the help of the scrum master, and it requires an active participation by the team members to complete it in a successful manner. The team members divide the user stories taken up in the sprint backlog into individual development tasks. Subsequently, the team members take up tasks for development depending upon their levels of expertise and experience.   

What is the nature of the sprint planning meeting?

The planning meeting generally occurs in two parts – the first part involving the product owner and the scrum master, in addition to the team members. The second part is attended by the team members, who may recall the product owner to the meeting if they need his or her help.

The first part

In the initial part of the meeting, the product owner shares his or her vision regarding what should be included within the sprint backlog based upon the importance of the requirements, or the user stories, available in the product backlog. The person discusses the sprint goal with the team, and explains about what the investors and the stakeholders desire regarding the functionality associated with the product backlog items. The sprint goal is also decided and carefully explained to the team members. One of the most important aspects is the discussion related to the acceptance levels of the user stories i.e. what the user story should satisfy in terms of criteria to be considered as “completed” or “done”. Ideally, the team members should make notes during the meeting so they can remember about the specifics associated with each product backlog item. If any member is unclear about any aspect pertaining to the user story, or how it should be developed, he or she is free to ask during this part of the meeting and get his or her confusions cleared.

The second part

The second part of the meeting is succeeded by a break, usually the lunch break. This part is important for the team members since they have to discuss amongst each other how the sprint backlog items should be segregated and broken down into individual tasks. Each story should be broken down into smaller parts so the team can easily develop it. Thereafter, the individual members of the team unanimously decide as to who should take up which tasks. This part requires a proactive participation, and the members should volunteer to take up work. Generally, the work is taken up based on expertise possessed by the team member. More experienced members can take up more tasks, while less experienced ones tread carefully by taking up easier stories which can be developed without much complexity. Eventually, the list is completed as to which of the user stories will be “processed” and developed by which team member.    

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

How Can A Scrum Master Be A Good Servant Leader?

What is understood by the servant leader role?

There are several interpretations of the servant leader role, and many experts have contributed their versions as to what the exact definition should include. However, to summarize all those definitions, the role can be best defined as a virtue, or a trait, which can put the priorities of others first, and maintain a humane attitude towards them. While a debate can extend indefinitely as to how the word “humane” should be understood, a person acting in the capacity of a scrum master might exhibit certain characteristics common to the role to be considered as an ideal servant leader.  

Listening

A good listener can grasp the finer points of a discussion and make informed decisions. It is very important to be sensitive to the team’s needs and the problems faced by them. The scrum master should listen carefully to what the team members have to say during the daily scrum meeting. He or she should make efforts to pick up clues and pointers pertaining to self-organization and try to encourage the team members to accept them. People have different types of natures, and while some are extroverts with an ability to express their views and opinions easily and loudly, many developers are of introvert types and may find it difficult to vocally express their ideas. The scrum master should be on the lookout as to what these types of individuals want to say, and help them to open up and express their views and opinions without any inhibitions. It is also equally important to detect any impediments faced by the team members, and advise them how to go about them.

Awareness

The awareness concerning a particular situation ought to be gained keeping in mind a holistic view to avail a better understanding regarding the ethics and moral values. It is very important for the scrum master to understand and look at situations from a much higher level than the rest of the team to gain a complete picture associated with a particular scenario. The person should ideally think above the role of a developer, and try to act more as a facilitator than anything else. It is important to remain detached with the team, yet remain close to it. 

The scrum master should maintain a proper balance between the two different parts of the same role. It becomes easy to implement scrum in a systematic manner if you remain detached, since it helps you to observe the workings as a third person. Scrum does not support active participation of the scrum master in leading the team directly by providing instructions to them. At the same time, the servant leader role supports compassion and closeness, which is only possible if you involve yourself on a personal basis with the team member. Therefore, it is important to be aware about both these antithetical requirements of the role, and carry it out by balancing both the aspects.   

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