Who are Stakeholders?

The term stakeholder creates a lot of confusion in Scrum. Usually the term is confused with the responsibilities of a Product Owner. Let us now clear all the confusion around it.

Best definition of stakeholders is that they have legitimate interest in the project and another important point to be noted is that stakeholders are not always product owners but product owners are always stakeholders.

Product owners help define the backlog the Scrum team and also help in prioritizing the work units of the Scrum Team and continually communicate the progress to the stakeholders.

Stakeholders are the purpose for which a Product or service is created in the first place. Stakeholders are the people who have certain necessities, wants and desires; thus in business terms they have certain requirements which needs to be fulfilled. It is the responsibility of the Scrum Team to fulfil the requirements of the Stakeholders and satisfy them. Usually stakeholders do not have clear understanding of what they need and even if they do they keep changing their minds very often. Usually figuring out the actual needs of a stakeholder is achieved through a lot of meetings with the stakeholders and also after a lot of trial and error.

The stakeholders are very vital to the success of the Scrum team as they keep reviewing the team’s products and progress and keep providing continual feedback. There could be many people, who have genuine interest in the Product, but not everyone should be taken in to account as Stakeholders – some are purely engrossed bystanders. Clear identification of the stakeholders who have requirements is as important as determining the exact market segment you need to target for your products.

So, now we get another important question. Who or what qualities make a good stakeholder in Scrum?

Good stakeholders are those who provide constant and constructive feedback to the Scrum team and help in improving the product. One big challenge is to manage other stakeholders who don’t support or just become part of the scene. Good teams need strong leadership that can facilitate positive discussion and create better services or products.

Hence to be successful in a Scrum project understanding the needs and requirements of the stakeholders plays a very critical part and most of the times make or break the project.

To know more please visit www.SCRUMstudy.com

Tools to Create Project Vision

A Guide to the Scrum Body of Knowledge (SBOK™) suggests four tools for the Create Project Vision process: Project Vision Meeting, JAD sessions, SWOT Analysis and Gap Analysis. With some soft skills and reliance on the dozen or more inputs possible for this process, you can keep the statement focused and usable.

The Project Vision Meeting

This meeting pulls together the Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner or company equivalents. These participants help identify the business context, business requirements, and stakeholder expectations in order to develop an effective Project Vision Statement. Scrum believes in closely engaging and collaborating with all business representatives to get their buy-in for the project and to deliver greater value.

JAD Sessions

A Joint Application Design (JAD) Session is a requirements gathering technique. It is a highly structured, facilitated workshop that enables Stakeholders and other decision makers to arrive at a consensus on the scope, objectives and other specifications of the project.

Each session consists of methods for increasing user participation, speeding development and improving specifications. Relevant Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner often use these sessions to outline and analyze desired business outcomes and focus their vision for the Scrum project.

SWOT Analysis

SWOT is a structured approach to project planning that helps evaluate the Strengths, Weaknesses, Opportunities and Threats related to a project. This type of analysis helps identify both the internal and the external factors that could impact the project. Strengths and weaknesses are internal factors, whereas opportunities and threats are external factors. Identification of these factors helps stakeholders and decision makers provide direction to the processes, tools and techniques to be used to achieve the project objectives. Conducting a SWOT Analysis allows the early identification of priorities, potential changes and risks.

Gap Analysis

This tool is a technique used to compare the current, actual state with some desired state. In an organization, it involves determining and documenting the difference between current business capabilities and the final desired set of capabilities. A project is normally initiated to bring an organization to the desired state, so conducting a Gap Analysis would help decision makers determine the need for a project. A Gap Analysis can look at current offerings and identify opportunities for products that are lacking in a particular market. Likewise, it can be used to identify missing software functionalities that can be developed into profitable products or services.

 The main steps of a Gap Analysis to identify the difference between current business capabilities and the final desired set of capabilities

With these tools, that Project Vision Statement can be the race-winning thoroughbred every company needs.

To know more please visit www.SCRUMstudy.com

Delivering Value in Scrum

A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people, and organizational capabilities. Usually, the results generated by projects are expected to create some form of business or service value.

Since value is a primary reason for any organization to move forward with a project, Value-driven Delivery must be the main focus. Delivering value is ingrained in the Scrum framework. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle.

One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

In order to provide Value-driven Delivery, it is important to:

• Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog.
• Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with project stakeholders showing them product increments at the end of each Sprint, enabling effective management of changes.
• Create Deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

The concept of Value-driven Delivery in Scrum makes the Scrum framework very attractive for business stakeholders and senior management. This concept is very different when compared with traditional project management models where:

• Requirements are not prioritized by business value.
• Changing requirements after project initiation is difficult and can only be done through a time consuming change management process.
• Value is realized only at the end of the project when the final product or service is delivered.

To know more please visit www.SCRUMstudy.com

Business Justification in SCRUM

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. The following steps capture how business justification is determined:

1. Assess and Present a Business Case

Business justification for a project is typically analyzed and confirmed by the Product Owner. It is documented and presented in the form of a project Business Case prior to Initiate phase and involves considering the various factors. Once documented, the Product Owner should create a Project Vision Statement and obtain approval of the Project Vision Statement from the key decision-makers in the organization. Generally, this consists of executives and/or some form of a project or program management board.

2. Continuous Value Justification

Once the decision makers approve the Project Vision Statement, it is then baselined and forms the business justification. The business justification is validated throughout project execution, typically at predefined intervals or milestones, such as during portfolio, program, and Prioritized Product Backlog Review Meetings and when major issues and risks that threaten project viability are identified. This could happen in several Scrum processes. Throughout the project, the Product Owner should keep the business justification in the Project Vision Statement updated with relevant project information to enable the key decision makers to continue making informed decisions.

3. Confirm Benefits Realization

The Product Owner confirms the achievement of organizational benefits throughout the project, as well as upon completion of the User Stories in the Prioritized Product Backlog.

The following figure summarizes the steps to determine business justification.

Analysis of business justification helps decision makers in understanding the business need for a change or for a new product or service and the need for moving forward with a project. It also helps the Product Owner to create a Prioritized Product Backlog along with the business expectations of Senior Management & Stakeholder(s).

To know more please visit www.SCRUMstudy.com

What is Self-Organizing?

Scrum believes that employees are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized. The preferred leadership style in Scrum is “servant leadership”, which emphasizes achieving results by focusing on the needs of the Scrum Team. Self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Product Vision is defined, the Product Owner, Scrum Master, and Scrum Team get identified. Also the Scrum Core Team itself works very closely with relevant Stakeholder(s) for refining requirements better. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project.

Self-organization as an essential principle in Scrum leads to the following:

• Team buy-in and shared ownership
• Motivation, which leads to an enhanced performance level of the team
• Innovative and creative environment conducive to growth

Although prioritization is primarily done by the Product Owner who represents the Voice of Customer, the self-organized Scrum Team is involved in task breakdown and estimation. During these processes, each team member is responsible for determining what work he or she will be doing. During the execution of a Sprint, if team members need any help with completing their tasks, Scrum addresses this through the regular interaction mandatory with the Daily Standup Meetings. The Scrum Team itself interacts with other teams through the Scrum of Scrums (SoS) Meetings and can look for additional guidance as required from the Scrum Guidance Body.

Finally, the Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint where properly completed deliverables are accepted. Since the Deliverables are potentially shippable, (and the Prioritized Product Backlog is prioritized by User Stories in the order of value created by them), the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint; and Scrum Teams in turn have the satisfaction of seeing their hard work being accepted by the customer and other stakeholders.

To know more please visit www.SCRUMstudy.com

Overcoming the Challenges faced by a Scrum Team

Scrum Team, also referred to as the development team, is responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.

Some of the challenges faced by a Scrum Team are:

Establish a common understanding of the customer’s requirements and the approach to develop the product
The Scrum Team consists of members with different levels of expertise, experiences, and viewpoints. So, all members should be aligned with the customer’s requirements to successfully develop the product and meet (or exceed) their expectations.

Function as a single unit to achieve the goals of the project
A Scrum Team is a cross functional unit that consists of members from diverse groups.This diversity might lead to friction within the team, especially in the formative stage. So, the team must strive to function as a single unit to avoid any internal conflicts that can disrupt work.

Create an environment that fosters collaboration among the Scrum Team members
Collaboration refers to a team proactively sharing thoughts, ideas and expertise to overcome challenges, or to improve a product’s quality. Collaborating can help a team deliver high quality products in a lesser time. Knowledge sharing is an important part of collaboration.

Be prepared to address customer’s change requests at any point during the product development lifecycle
Scrum projects are characterized by high rates of changes, depending on the customer’s requirements. Change requests may be initiated due to fluctuating market conditions, change in the preferences of end users, financial parameters, etc. So, the Scrum Team members should be able to accommodate change requests as the objective of a Scrum project is deliver functionality of the highest value to the customer.

Possess some business skills to ensure smooth communication with Product Owners and customers
Scrum Teams are often required to interact with Product Owners and sponsors. They might be required to negotiate with the Product Owner to decide which features can be delivered during a sprint or which features might contribute to the highest value. While the Scrum Team does possess technical skills, it is important that the team also possess adequate business knowledge to be able to better interact with the Product Owner.
 
Ensure team velocity is sustainable and that the team delivers the committed work
The Scrum Team should work at a pace that is sustainable. This means that the team should neither over estimate nor under estimate tasks. Estimating may be difficult initially. However, after a few sprints, teams should be able to estimate with more accuracy.
Since a sprint is time-boxed, the team must find an optimal rhythm to ensure that it meets the objectives of a sprint a time bound manner.

Ensure continuous process improvementThe Scrum team is responsible for continual process improvement over the course of a project. Teams must proactively participate in Daily Standup Meetings, Retrospect Sprint Meetings, and Retrospect Project Meeting to share their learning and brainstorm for process improvement.

To know more please visit www.SCRUMstudy.com

All about Retrospect Sprint Meeting

How is the Retrospect Sprint Meeting related to the ‘inspect-adapt’ aspect of Scrum? The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend. One team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right.

Primary objectives of the meeting are to identify three specific things:

1. Things the team needs to keep doing: best practices
2. Things the team needs to begin doing: process improvements
3. Things the team needs to stop doing: process problems and bottlenecks
4. These areas are discussed and a list of Agreed Actionable Improvements is created.

Other tools used in the Process of Retrospect Sprint are:

1. ESVP
2. Speed Boat
3. Metrics and Measuring Techniques
4. Scrum Guidance Body Expertise

The outputs of the Retrospect Sprint are:

1. Agreed Actionable Improvements
2. Assigned Action Items and Due Dates
3. Proposed Non-Functional Items for Prioritized Product Backlog
4. Retrospect Sprint Log(s)
5. Scrum Team Lessons Learned
6. Updated Scrum Guidance Body Recommendations

To know more please visit www.SCRUMstudy.com