Learn How to Conduct an Effective Backlog Grooming Session

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any revised estimates), and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.

Product Backlog Review Meeting

Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.

Backlog Grooming Session

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.

Backlog Grooming Techniques

• Develop Epic(s)
• Create Prioritized Product Backlog
• Conduct Release Planning
• Create User Stories
• Approve, Estimate, and Commit User Stories
• Create Tasks
• Estimate Tasks

Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analysed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.

To Know More,Please Visit www.scrumstudy.com

Value-based Prioritization in SCRUM

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization.

Prioritizing can be defined as determining the order and separating what must be done now, from what needs to be done later. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals. Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices.

Scrum, however, uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis.

Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.

Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value. The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance. Sometimes, a customer may mandate all User Stories to be of high priority. While this might be true, even a list of high-priority User Stories needs to be prioritized within the list itself. Prioritizing a backlog involves determining the criticality of each User Story. High-value requirements are identified and moved to the top of the Prioritized Product Backlog. The processes in which the principle of Value-based Prioritization is put into practice are Create Prioritized Product Backlog and Groom Prioritized Product Backlog.

Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks and uncertainty as they may have negative consequences associated with them. This should be taken into account while prioritizing User Stories on a value-based approach (refer to the Risk chapter for more information). The Scrum Team also alerts the Product Owner of any dependencies that arise out of implementation. These dependencies must be taken into account during prioritization. Prioritization may be based on a subjective estimate of the projected business value or profitability, or it can be based on results and analysis of the market using tools including, but not limited to, customer interviews, surveys, and financial models and analytical techniques.

The Product Owner has to translate the inputs and needs of the project stakeholders to create the Prioritized Product Backlog. Hence, Value, Risk or uncertainty and Dependencies are the three factors considered while prioritizing the User Stories in the Prioritized Product Backlog.

Thus prioritization results in deliverables that satisfies the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.

To Know More,Please Visit www.scrumstudy.com

Quality Comes in Large Quantities in Scrum

Competing video game companies—one that operates inside of the Scrum framework and one that does not—release similar games around the same time. The graphics and story-lines in each are fantastic. As gamer’s button mash their way through the campaigns, however, disparities emerge. Unlike its competitor, the company that operates inside of the Scrum framework finds little need to release patches for various game-play glitches. This is because those issues were neutralized during the company’s iterative quality testing throughout the production process—also known as Sprints—rather than saving that critical part of the process for the last minute.

In Scrum, quality is defined as the ability of the completed product or deliverable to meet the Acceptance Criteria and achieve the business value expected by the customer, according to A Guide to the Scrum Body of Knowledge (SBOK™ Guide). From small projects with six team members to large, complex projects with hundreds of team members, Scrum can be applied effectively to ensure quality is a staple in the production process.

To achieve this, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through iterative quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks—development, testing, documentation—are completed as part of the same Sprint by the same team. This ensures that quality is inherent in any deliverable created as part of a Sprint.

Continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) along with actual increments of the product being delivered at the end of every Sprint reduces the gap between customer expectations and actual deliverable.

Between competitors, oftentimes it’s “game on.” But when a company commits to quality while operating within the Scrum framework, it’s game over.

To Know More,Please Visit www.scrumstudy.com

Sprint Retrospective Meeting

Sprint Retrospective is a meeting convened by the Scrum Master in which the team talks about the previous sprint and decided on how to make the next sprint productive. This meeting differs from a Sprint Review meeting. In Sprint review meeting the team looks into what the team is currently working on whereas the Retrospective meeting talks about how they are working.

The team discusses on processes , communication, environment, artefacts and tools, practices.

Scrum is a framework that needs to be adjusted appropriately for a project, team and circumstance. The Sprint Retrospective meeting is a valuable instrument that allows a team to constantly develop and progress throughout the project.

In Scrum it is very key for all team members including the Product owner and Scrum Master to get an opportunity to voice their opinion in an truthful atmosphere. In some cases it may be beneficial to get an external enabler to attain the maximum advantage from retrospective. Also in cases where emotional conflicts are present in the team an impartial facilitator could be of help.

The duration of this meeting is usually time boxed to 3 hours and The participants of the meeting would be team members, product owner and scrum Master. However the attendance of the product owner is uncomplelled.

The meeting concentrates and getting answers on the below questions:

• What are the positives during the sprint?
• How to improve the next Sprint?

Irrespective of who joins the meeting , the atmosphere for Sprint Retrospectives must be harmless for participants. This infers that participants are required to be truthful and must be honest and apparent while considering others with respect. Issues performance and improvement can flare up in retrospectives. This can be handles by having a professional facilitator in the meeting.

Sprint Retrospectives are basically a method used to divulge the practices and activities of the Team to itself. It is considered that when a self organising team is self aware , it provides opportunities to correct one-self and improve. When a self-organizing system becomes self-aware, it self-corrects and deliberately improves when given the tools to do so.

However an ineffectively run Sprint Retrospective can do more harm than good to the team. It unnecessarily consumes the time of the team and can also be destructive to the team. Hence as stated earlier a professional facilitator is recommended to conduct the meeting at least when the team is newly following Scrum.

When Sprint Retrospectives work well, the team becomes more focused and  productive. Excellent teams do not simply appear. They evolve over time  and Sprint Retrospectives are a key ingredient in  for this.

To Know More,Please Visit www.scrumstudy.com

What is a Persona?

Personas are highly detailed fictional characters, representative of the majority of users and of other stakeholders who may not directly use the end product. Personas are created to identify the needs of the target user base. Creating specific Personas can help the team better understand users and their requirements and goals. Based on a Persona, the Product Owner can more effectively prioritize features to create the Prioritized Product Backlog.

Creating a Persona

Creating a Persona involves assigning a fictional name and preferably a picture, like a stock image, to the character. The Persona will include highly specific attributes such as age, gender, education, environment, interests, and goals. A small group of users are selected to form the focus group and this group may be selected randomly from a large pool of users or can be selected specifically to represent all the major Personas being targeted. A quote illustrating the Persona’s requirements can be included as well. Below is an example of a Persona for a travel website.

An example for this concept Personas

Vanessa is a 39 year old resident of San Francisco. She is pursuing her passion for traveling after having a highly successful career as an attorney. She likes to have options while picking air travel and accommodation services so that she can choose the best and the most affordable. She gets frustrated 

To Know More,Please Visit www.scrumstudy.com

All About User Story Prioritization

At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller. For example, Kano analysis has limitations because there won’t be any dis-satisfiers or exciters. Without a significant number of stakeholders, especially users, the 100-point method has limited value. The MoSCoW technique also has limitations because there won’t be any “nice to have” or “Won’t have” features at program and portfolio levels.

Some techniques used to prioritize the User Stories or requirements in the Prioritized Product Backlog, on the basis of business value are presented below:

• MoSCoW Prioritization scheme—The MoSCoW prioritization scheme derives its name from the first letters of the phrases “Must have,” “Should have,” “Could have,” and “Won’t have”. This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with “Must have” User Stories being those without which the product will have no value and “Won’t have” User Stories being those that, although they would be nice to have, are not necessary to be included.

• Paired Comparison—In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.

• 100-Point Method—The 100-Point Method was developed by Dean Leffingwell and Don Widrig (2003). It involves giving the customer 100 points they can use to vote for the User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.

• Kano Analysis - The Kano analysis was developed by Noriaki Kano (1984) and involves classifying features or requirements into four categories based on customer preferences:

1. Exciters/Delighters: Features that are new, or of high value to the customer
2. Satisfiers: Features that offer value to the customer
3. Dissatisfiers: Features which, if not present, are likely to cause a customer to dislike the product, but do not affect the level of satisfaction if they are present
4. Indifferent: Features that will not affect the customer in any way and should be eliminated

Kano Analysis

Interestingly, features usually move down the classification list over time; customers will come to expect features (e.g., cameras on phones) and these features will move from being exciters/delighters to satisfiers and eventually to dissatisfiers.

At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller.

To Know More,Please visit www.scrumstudy.com

Learn How to Conduct an Effective Backlog Grooming Session

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any revised estimates), and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.

Product Backlog Review Meeting

Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.

Backlog Grooming Session

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.

Backlog Grooming Techniques

• Develop Epic(s)
• Create Prioritized Product Backlog
• Conduct Release Planning
• Create User Stories
• Approve, Estimate, and Commit User Stories
• Create Tasks
• Estimate Tasks

Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analysed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.

To Know More,Please Visit www.scrumstudy.com