The Purpose And Goals Of Carrying Out Product Backlog Refinement In Scrum

The official scrum guide mentions about carrying out routine maintenance activities to update the product backlog, or to carry out the product backlog refinement. The exact time to be invested in the grooming activity depends upon the management, and how scrum is to be implemented in the project. A rule-of-the-thumb followed is to put in approximately 10% of the time utilized during the sprint activity, into the grooming activity. It is important to be clear regarding some of the aspects associated with product backlog refinement.

Purpose and goals of carrying out the refinement
The primary reason why the product backlog should be refined is to update or rebuild the backlog so that it remains consistent with the requirements provided by the stakeholders with regards the new features and functionalities to be included in the project. Another reason is to review existing user stories or product backlog items and decide whether they are still useful or pertinent from the development point of view, and to update the acceptance criterion and the explanation detailed in each PBI. 

It is recommended to use the “DEEP” method - detailed appropriately, estimated, emergent, and properly ordered – while prioritizing the user stories within the backlog. Larger stories or epics should be systematically broken down in to more manageable smaller ones, proper estimation by assigning relevant story points to the PBIs should be carried out,  user stories should be rearranged as per the new priorities,  and the queries regarding the development of user stories during the sprint should be effectively answered by the product owner. Whenever a meeting is planned to refine the PBIs, the objective should be to carry out enough refinement work so that it lasts for at least three future sprints.

Product Backlog Grooming In Scrum

Duration and frequency of the grooming activity 

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged.

In practice, ideally time equivalent to 10% of the total time spent during the sprint activity should be allotted for the product refinement. For a two week sprint consisting of a total of 6 working hours per day and 14 sprint days per sprint, the time to be allotted should be approximately 10% of 6 hours x 14 days  = 8.4 hours (10% of 6 hours x 14 days = 84 hours). This could be rounded up to one working day. Since the refinement activity is to be carried out on a consistent basis, investing additional time could lead to decreased productivity and an extended product release date – something that should be avoided.  In actual practice, this rule suffices to a great extent.

 
Who should participate in the grooming activity?
Besides the product owner, the grooming sessions should be attended by the development team members and the scrum master. The stakeholders can participate in the sessions too, but their participation should be a passive one, and they should not volunteer opinions, or try to disturb the sessions in any way or manner. Moreover, the product owner should try to limit their numbers during the sessions so it does not become overcrowded and difficult to hold the meeting.

Maintaining a proper approach
It is important to remain focused, and the product owner should be clear whether a particular product backlog item should be estimated again, or it ought to be detailed in greater depth, and additional explanation provided regarding its acceptance criteria. The team members should remain focused upon understanding the PBIs and if required they should demand explanations regarding the acceptance criteria and how the development should be carried out during the sprint activity.

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

The Responsibilities Of A Product Owner

As far as scrum methodology is concerned, the product owner plays a very important part in creating new products, and enhancing the value of existing ones for an organization. Many businesses struggle to implement the role in an effective manner, but often fail to do so. There are several reasons why this happens. One of the commonest causes is that the organization fails to properly understand the exact role played by the product owner, or may be unsure as to what kind of role is best suited for their project related requirements. The product owner “owns” the product on behalf of the investors and the stakeholders. The person is responsible for the success of the project, and is answerable to the management for the project.
 

A multifaceted role
The role of a product owner varies in real life depending upon several factors such as the market conditions, product life cycle, and management related concerns. The aims and objectives of a project depend upon the type and nature of the product to be developed, and how the owners desire to manufacture and market the product. The product owner has to oversee the completion of the project, whatever the project related requirements might be. There are times when the person has to think as an owner and ensure the project is being properly executed, so it benefits the management. The person may be required to act as a facilitator and coordinate the working of the team. It may be required to think like an entrepreneur while suggesting project related ROI solutions to the stakeholders. The role is not an easy one, and the product owner required to be a bit of everything – a team leader, entrepreneur, project manager, facilitator, and a product owner! 
 

Responsibilities of the product owner
A product owner should take up certain responsibilities:

People

• Understand the needs of customers and end users
• Collaborate with the development team
• Successfully manage the stakeholders

Strategy

• Create an effective business model
• Working out proper strategies for conducting sprint planning meetings, sprint review meetings, and sprint retrospective meetings 
• Develop the product definition and road map
• Define and explain the user experience and the product features

Learning and delivery

• Set up the sprint goal, detail the user stories, and decide what to do next
• Collect relevant data and analyze it for goal validation
• Update the business model and product features as per need
• Monitor and track the project progress (time and budget)
• Coordinate with the stakeholders for the product launch

Scrum

• Have the correct vision about how and where to take the product
• Prioritize the product backlog as per business value associated with user stories  
• Advise and offer help to the scrum master when asked for or required
• Analyze and understand the business model including the value proposition as well as the business benefits desired from the product development
• Ensure effectual sprint goals are set up and followed
• Choose the correct research and/or validation technique to exhibit the product increment

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

How Are Sprint Review Meetings Different From Sprint Retrospective Meetings In Scrum? Where Do They Differ?

The primary objective of a sprint review meeting is to present the development work carried out by the development team, avail proper and reliable feedback regarding the work completed until then, and support collaboration. The review meetings are a part of the inspecting and adapting process associated with scrum. Scrum methodology supports self-correction and self-learning methods. There are several processes, which help the team to self-correct, and find where the project is heading. Both the sprint review and the sprint retrospective meetings are conducted after a particular sprint is completed. It is important not to get confused between the two. 

Sprint review meeting
Sprint reviews are informal meetings, and specially conducted to present the work – user stories and development tasks – carried out and completed by the team members during the sprint. The work completed is ideally demonstrated in the form of a “demo” to the stakeholders and investors. The main idea is to put the completed work in front of individuals who have invested into the project, so they can get an idea regarding the quality and the quantity of development carried out. It helps to increase the user participation levels. The stakeholders can subsequently accept the work, reject it if they are not satisfied, or if the work does not adhere to the acceptance levels as specified at the time of creating the product backlog items. The product owner represents the stakeholders’ interests, and he or she decides about the work during the meeting. In reality, the stakeholders may attend the meeting, but they are passive attendees and are not allowed to speak or volunteer opinions during the review. The product owner does all the talking. 

Goals

• Present the sprint development work to the product owner
• Get the user stories and tasks accepted as “Done”
• Rejected and incomplete tasks to be transferred back to the product backlog

Who attends?

• Product owner, team members, scrum master, stakeholders (only if interested)

Time boxed to

• 1 hour per week of the sprint duration/length (I.e. for a 2-week sprint, the time to be allotted = 2 hours for the meeting and for a 4-week sprint = 4 hours, and so on…)

 

Sprint retrospective meeting
The entire team, product owner, and the scrum master ought to put in efforts to find out about what lessons need to be learnt from prior sprints, what more can be done to streamline the sprint process, and what kind of pitfalls and problems are likely to arise in the future and how they can affect the project.    

Goals

• What can and should be learnt from the sprints already completed
• Identify potential pitfalls and impediments likely to affect the team during the sprint activity
• Plan for the next print

Who attends?

• Product owner, team members, and the scrum master

Time boxed to

• 3 hours

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

The Dos And Don’ts Of Servant Leader Role For Scrum Masters

What is understood by the term “servant leader”?

Several experts have tried to define the role of a servant leader, as to what it should ideally include, and what scrum masters should do to be considered as good servant leaders. To summarize what the authors have to say about the role, individuals desiring to function as good servant leaders should be compassionate, exhibit humane characteristics, act as a facilitator, and be a mentor for individual team members. Rather than discussing in details about each characteristic, the role can be briefly understood by going through the Dos and Don’ts associated with the servant leader role.

What the scrum master should ideally do to become a good servant leader

• Protect the team and its members from distractions and diversions
• Facilitate the planning activities and sessions
• Encourage team members to participate in sprint reviews and retrospectives  
• Implement scrum methodology and coach scrum to team members
• Help the team to collaborate
• Publicly represent and protect the team’s position
• Anticipate issues and problems likely to occur during the sprint activity
• Discover ways and means to remove the impediments faced by the development team
• Ensure daily scrum meetings are properly conducted as per scrum principles and rules
• Support and encourage transparency while implementing the project
• Properly understand and present the team’s progress to the investors and stakeholders
• When necessary, arbitrate on behalf of the team members

What should be avoided or prevented

·      Provide instructions directly or indirectly to the development team
	The scrum master should act as a facilitator and help the team members to find solutions on their own through guidance, advice, and suggestions.
·      Manage the daily scrum meeting
	Rather than directing the team and providing development related solutions, the person should supervise scrum and ensure the team members follow it properly.
·      Estimate the work taken up by the team
	If the team is coming up with an estimate, the scrum master should not interfere by suggesting or advising as to what the estimate should ideally include. If required, the person can arbitrate on behalf of the team.
·      Remain uninvolved or be unconcerned about where the team is heading
	Always try to maintain a holistic attitude about how the project is proceeding, and how the project can be affected by the work carried out by the development team. One should be clear about the project goals and how the team is currently achieving them.

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! 

All About Sprints And Sprint Meetings – In A Nutshell

Overview

The sprint is the main point of activity for any scrum project. During a sprint, the development team delivers a certain portion, or a “slice” of the actual development activity to be carried out as defined in the product backlog. During a sprint, the development activity can include a host of other things in addition to the actual development work. This can include the documentation, user manual creation, testing and debugging functionality, or even checking cross platform compatibility. Each activity during the sprint can be understood as a task. When user stories are transferred to a sprint backlog by the product owner, the development team further segregates each user story into its individual tasks i.e. each story is broken down into smaller tasks to make it more manageable and developable. Each user story is assigned a story point which determines its potential value. The story points help to generate an estimate as to how many user stories can be included in the sprint backlog based upon the team’s ability to carry out the development.

The entire development is carried out in the form of sprints. Usually, a sprint lasts for two weeks, however, technically they can extend up to three to four weeks depending upon how scum is being implemented by the product owner and the scrum master. Sprints are also known as “iterations” in more simple terms. Sprints are supervised by scrum masters. As per the scrum guide, a scrum master should be a passive participant during the sprint. His or her job is to ensure that the team members properly follow scrum rules when the sprint is underway. At the end of the sprint, user stories are developed into shippable products, each with its own functionality and importance. 

 

Sprint planning meeting

A sprint planning meeting is held before the sprint commences. It is attended by the product owner, the team members, and the scrum master. During the sprint planning meeting, the product owner transfers some of the user stories from the product backlog into the sprint backlog for development purposes. The meeting is actually held in two parts:

1. First half of the meeting

During the first half of the meeting, the product owner explains about the user stories which have been included in the sprint backlog. He or she explains about the acceptance levels and the importance of the user stories to the stakeholders. Team members are free to ask questions to the product owner if they require explanations regarding some of the user stories.

2. The second half of the meeting

During second half of the sprint planning meeting, the team members breakdown the user stories in the sprint backlog into smaller, and more manageable tasks, which are taken up for development purposes. Generally, the team members decide unanimously how to distribute the tasks and user stories amongst themselves. Team members take up work as per their skill sets and development expertise.

Sprint retrospectives

A sprint retrospective meeting is held after the sprint is over. The main purpose of the meeting is to evaluate the sprint which has just completed, and what lessons should be learnt from it. A lot of discussion occurs during the meeting, and both the product owner and the scrum master try to envision what could possible go wrong in the future sprints. They contribute their expertise as well as their experience, and try to identify impediments, and seek solutions for potential problems which may occur in the near future.  

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