Scrum and Kanban, alike or different?

One of the criteria for selecting an agile tool in terms of Kanban or Scrum can be the time required. One of these methodology works well when there is shortage of time in terms of deadlines; the other one works well in situations where more time is required to carry out tasks when a diminutive iteration cannot satisfy the work. Testing should be carried out at all levels and processes as perpetual testing can only raise the level of quality in terms of software or a code.

Kanban processes can enable enhancement of the quality of software from its commencement till project delivery. The reason, as we know, is because of its focus on system thinking. Kanban restricts the capacity of tasks which can be found anywhere in the complete cycle of the work-in-progress limit. This can be advantageous too as total focus can be directed towards solitary work packages one at a time and ensuring thus the quality of the outcome. In situations entailing releases within a less time period, Kanban is a good choice as since total focus is given toward single tasks, rendering them ‘completed’ once they are done with. So, Kanban works fine in this type of scenario.

Good quality is what one can see with relation to the work right from the conception to the end. Understanding the requirements, design related with transitioning activities, development activities, testing and ending with releasing is how the Kanban workflow would contain right from the conceptual stage.

Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.

Segregation of the quantity of work that would be possible to be done within a particular time frame is one of the advantages of using Scrum.

Both approaches are more or less about effective change management in the sense that they are very much alike pertaining to learning curves, focus, progress and change.

To know more please visit www.SCRUMstudy.com

7 C’s of Scrum

Scrum is an iterative and incremental product development framework which ensures that the highest value is delivered to the consumer or the customer. 7 C’s of Scrum are the characteristics which ensure the highest value delivery through scrum framework. These C’s are discussed below:

1. Consumer Centric: The focus of the Product Owner, Scrum Master and The Scrum Team is to understand the Consumer requirements, meet the acceptance criteria of the products, deliver high value and in turn have a satisfied customer.
2. Continuous Delivery of Value: Ship deliverable process ensures that there is continuous development and delivery of the project deliverables rather than completing the project in one go and delivering it to the client.
3. Constant Feedback: Daily Stand-up meetings are held wherein each of the scrum team members will let the other team members know about the work he completed yesterday and what he will do today. Also, he let others know about the difficulties he faced in completing the deliverable. The Scrum Master then will work to remove the impediments obstacles faced by the team members.
4. Continuous Improvement: Scrum is an iterative, incremental process in which the errors are identified quickly and also there is scope to change the features of the product under development and add new features to it with less cost. This leads to overall reduced cost of errors at the end of the project.
5. Compliance: The continuous feedback, flexibility and adaptive nature of the Scrum Teams will help in incorporating the new requirements and changes easily. There is also sprint retrospect meetings held to ensuring the deliverables are in compliance with the requirements.
6. Clarity: All the team members share their knowledge and work progress. They ensure information sources of the work in process like the Burndown chart are accessible to all the team members and hence there is clarity among the team members about the project progress.
7. Collective Ownership: The team members are involved in Estimating the tasks and efforts and approving the user stories. They are empowered to take decision and hence this allows them to take the ownership of the tasks.These are the C’s of Scrum which ensure that the products or Service developed by the Scrum Team is with minimal errors and reduced cost of errors and rejections.

To know more please visit www.SCRUMstudy.com

Various Activities in Scrum Processes

Scrum processes address the specific activities and flow of a Scrum project. In total there are 19 processes which are grouped into five phases.

Please take a look at these processes and the activities listed under to them in order to understand the flow of a Scrum Project better.

Initiate

1. Create Project Vision—in this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.
2. Identify Scrum Master and Stakeholder(s)—in this process, the Scrum Master is identified using specific Selection Criteria.
3. Form Scrum Team—in this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.
4. Develop Epic(s)—in this process, the Project Vision Statement serves as the basis for developing Epic(s). User Group Meetings may be held to develop Epic(s).
5. Create Prioritized Product Backlog —in this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
6. Conduct Release Planning—in this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

Plan and Estimate

1. Create User Stories—In this process User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.
2. Approve, Estimate, and Commit User Stories—In this process the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.
3. Create Tasks—In this process the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.
4. Estimate Tasks—In this process the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.
5. Create Sprint Backlog—In this process the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint.

Implement

1. Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.
2. Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.
3. Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

Review and Retrospect

1. Convene Scrum of Scrums—In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved.
2. Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.
3. Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

Release

1. Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
2. Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

To know more please visit www.SCRUMstudy.com

How can marketing team benefit from Scrum?

Scrum as an Agile methodology is currently most popular in IT development teams. However, that does not mean that it cannot be effectively used in other domains. In fact, as an Agile methodology of managing projects, it can be used wherever people work on projects on a regular basis. It can be used in a particular division of a company – like new product development in an automobile company, and can also be used in a particular function of a company – like marketing. This article will highlight how Scrum methods can be used very effectively to manage marketing projects.

Marketing as a function revolves around projects. Marketing professionals work on a variety of projects – ad campaigns, email campaigns, product prototyping, market research etc. More time is spent on projects rather than operational activities. Hence, Scrum can be especially beneficial for marketing teams.

Let’s say the marketing team is tasked with the project of launching a new car model. How can it use Scrum? Well, it actually is quite simple (one of the basic objectives of Scrum – to keep it simple). You start off with stating the project vision – launching the car in a defined area, say, the state of California. Then you need someone to spearhead the whole project – the Scrum Master. He/she will decide who all will be part of the Scrum team. These have to be people who will actually be doing the various tasks in the project and not the ones who simply have an interest in the project.

So now you have the people who will be working on the Scrum project. What next? The team needs to understand the customer requirements. These are defined in the form of User Stories. In our case, two of the user stories might be ‘I need to test drive the car before I buy it’ and ‘I need to know all its performance specifications’.

The User Stories are approved and entered into what is called the Prioritized Product Backlog. It is the master document which guides the team in the project. It contains the User Stories and the tasks which are required to fulfill the requirements for each of the user stories. So in our example, the first User Story about test drives will include tasks like ‘Decide number and variants of test cars needed’, ‘Brand the test cars’, ‘Create a test drive feedback form’, ‘Decide on the tasks to be performed by the salesperson before the test drive’, etc. It then decides on a Release Planning Schedule which lays out the schedule of shipping out completed deliverables to the customers. The team then estimates the time required for the various tasks. Based on the above, a collective decision is taken on which all tasks will be taken up in the first round – called Sprint in Scrum. A Sprint duration can vary from a week to a few weeks.

The team then works on completing the tasks in a particular Sprint. To ensure that things are on track, the Scrum team has a Daily Standup Meeting which is time-boxed to normally 15 minutes to half an hour, in which all the members stand around and discuss the status of the different tasks. Tasks are entered in post-it notes and stuck on to a whiteboard with 3 columns – ‘To be done’, ‘In Process’ and ‘Completed’.  The team then works on the tasks from the first column to the third column. At the end of a Sprint, when the team has hopefully completed all the tasks, a Sprint Review Meeting takes place where the team discusses what went right and what are the improvement opportunities. At designated points in time as laid out in the Release Planning Schedule, the team ships out completed deliverables.

This process continues till all the deliverables and tasks are completed in the Scrum project. The high level of involvement and communication involved in the Daily Standup Meetings is the key to an effective implementation of Scrum. Thus, by following the above process, marketing teams can ensure speedy completion of projects with high quality outputs without getting bogged down by a lot of documentation and processes.

To know more please visit www.SCRUMstudy.com

Is Value-Driven Delivery the Key to Scrum’s Success?

One of the aspects of Scrum that attracts business stakeholders is the delivery of maximum business value in minimum span of time. To achieve this goal, Scrum is relies on the principle of value-driven delivery. Also, as projects involve collaborative effort to either create new products or services or to deliver results as defined in the Project Vision Statement, they are usually affected by constraints of time, cost, scope, quality, people and organizational capabilities.

To overcome these constraints, value-driven delivery must be the main focus. 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 and show them product increments as each is created and allow them to manage changes effectively.
• 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 is quite different when compared with the principles of traditional project management models where:

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

Thus value-based delivery helps in delivering the maximum business value in the least amount of time to the customers and becomes one of the key aspects behind the success of Scrum.

To know more please visit www.SCRUMstudy.com

How to form a Scrum Team?

Forming a Scrum Team, is nothing but another process in the Scrum Project. It is one of the 6 process in the Initiate Phase. In this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.

The Scrum Team is the core of any Scrum project and getting the right team members is important for successful delivery of Scrum projects. Scrum Team members are generalist-specialists in that they have knowledge of various fields and are area experts in at least one.

Beyond their subject-matter expertise, it is the soft skills of team members that determine the success of self-organizing teams.

Ideal members of the Scrum Team are independent, self-motivated, customer-focused, responsible, and collaborative. The team should be able to foster an environment of independent thinking and group decision-making in order to extract the most benefits from the structure.

The Scrum Team, sometimes referred to as the Development Team, is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.

Scrum Teams are cross-functional and self-organizing. The team decides the amount of work to commit to in a Sprint and determines the best way to perform the work. The Scrum Team consists of cross-functional team members, who carry out all the work involved in creating potentially shippable deliverables including development, testing, quality assurance, etc.

Identifying the Scrum Team is the responsibility of the Product Owner, often in consultation with the Scrum Master.

Team Building Plan

Since a Scrum Team is cross-functional, each member needs to participate actively in all aspects of the project. The Scrum Master should identify issues with team members and address them diligently in order to maintain an effective team.

To build team cohesion, the Scrum Master should ensure that relationships among the team members are positive and that the team members are unified in achieving the overall project and organizational goals, thus leading to greater efficiency and increased productivity.

In this context, it is important to study popular HR theories and their relevance to Scrum. Continue with our posts to learn more on Scrum Methodology, Scrum Certification and Scrum Management.

To know more please visit www.SCRUMstudy.com

Roles and Responsibilities of a Scrum Master

The first thing we have to be sure when dealing with SCRUM master is whether they have a full time Scrum masters, and the second question we have to ask is if what do they do?

We usually don’t find a full time scrum master.  Scrum master is described by scrum guide as one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.

Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.

If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. He has to devote himself in helping the team with their work.

The first step is to train the project managers in Agile. Try to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.

Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.

Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.

This has to be followed for the initial six months, until the team gets used to the concept of Scrum.

Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.

Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,

Rearrange management structure, now instead of a functional manager we have a delivery manager.

The delivery manager is now accountable for training agile.

Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more Agile mature.

The bottom line here is we have less people doing same amount of work. This is without the need of a dedicated scrum master, Along with this we need to have a contingent plan.

To know more please visit www.SCRUMstudy.com

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

The story behind origin of Scrum

In the mid 80’s, Hirotaka Takeuchi and Ikujiro Nonaka defined a flexible and all-inclusive product development strategy where the development team works as a unit to reach a common goal. They described an innovative approach to product development that they called a holistic or “rugby” approach, “where a team tries to go the distance as a unit, passing the ball back and forth.” They based their approach on manufacturing case studies from various industries.

Takeuchi and Nonaka proposed that product development should not be like a sequential relay race, but rather should be analogous to the game of rugby where the team works together, passing the ball back and forth as they move as a unit down the field. The rugby concept of a “Scrum” (where a group of players form together to restart the game) was introduced in this article to describe the authors’ proposal that product development should involve “moving the Scrum downfield”.

Ken Schwaber and Jeff Sutherland elaborated on the Scrum concept and its applicability to software development in a presentation at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference held in 1995 in Austin, Texas. Since then, several Scrum practitioners, experts and authors have continued to refine the Scrum conceptualization and methodology. In recent years, Scrum has increased in popularity and is now the preferred project development methodology for many organizations globally.

To know more please visit www.SCRUMstudy.com

Confirming Benefits in Scrum

Throughout a project, it is important to verify whether benefits are being realized. Whether the products of a Scrum project are tangible or intangible, appropriate benefit realization planning and verification techniques are required to confirm that the project deliverables with benefits and value are being created by the Scrum team members. So a well-structured benefit realization plan helps the teams map benefits of individual projects to the overall programme and corporate strategic objectives. This also helps in tracking the identified benefits even after completion of Scrum project and handover of deliverables

At the beginning of the project, all the project outputs, outcomes and benefits expected by the user groups and other key stakeholders should be identified and documented. And a means of measuring benefits, key responsibilities and accountabilities associated with benefits, time of benefit realization, etc. should also be agreed. At pre-determined intervals, the team should review the benefit realization plan to assess the status of expected benefits and to incorporate any changes in the forecast of realization of benefits.

Now, let’s look at some of the ways of confirming benefits. Some useful techniques are use of prototypes, simulations, workshops, demonstrations etc. Demonstrating prototypes to customers and simulating their functionalities are commonly used techniques for confirming value. Often, after using the features or having them demonstrated, customers can more clearly determine whether the features are adequate and suitable for their needs. They might realize a need for additional features, or may decide to modify previously defined feature requirements. In product development, this customer experience has come to be known as IKIWISI (I’ll Know It When I See It).

Through demonstrations or access to early iterations, customers can also evaluate to what degree the team has successfully interpreted their requirements and met their expectations.

To know more please visit www.SCRUMstudy.com

Risk Management in Scrum

Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to its success or failure. Risks with a potential for positive impact on the project are called opportunities, whereas threats are risks that could negatively impact a project. Managing risk must be done proactively, and it is an iterative process that should begin at project inception and continue throughout the life of the project. The process of managing risk should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.

Risk Management consists of five steps:

• Risk identification: Using various techniques to identify all potential risks.
• Risk assessment: Evaluating and estimating the identified risks.
• Risk prioritization: Prioritizing risk to be included in the Prioritized Product Backlog.
• Risk mitigation: Developing an appropriate strategy to deal with the risk.
• Risk communication: Communicating the findings from the first four steps to the appropriate stakeholders and determining their perception regarding the uncertain events.

Risk identification involves the Scrum Team members who attempt to identify all risks that could potentially impact the project. Only by looking at the project from different perspectives, using a variety of techniques, can they do this job thoroughly.

Risk assessment helps in understanding the potential impact of a risk, how likely it is to occur, and when the risk could materialize. The overall effect on business value should be estimated; if that impact is significant enough to outweigh the business justification, a decision must be made whether to continue the project. The assessment of risks is done with regard to probability, proximity, and impact. Probability of risks refers to the likelihood of the risks occurring, whereas proximity refers to when the risk might occur. Impact refers to the probable effect of the risks on the project or the organization. To estimate the probability of a risks, various techniques may be used, including Probability Trees, Pareto Analysis, and a Probability and Impact Matrix.  In addition to probability, risk assessment also evaluates the potential net effect of risks on the project or organization. These effects can be estimated using techniques such as Risk Models and Expected Monetary Value.

Under the risk prioritization step, Identified Risks are captured in a Prioritized Product Backlog—so a Prioritized Product Backlog could also be referred to as a Risk Adjusted Prioritized Product Backlog. The prioritized User Stories from the existing Prioritized Product Backlog and the prioritized list of risks are then combined to create an updated Prioritized Product Backlog which includes the Identified Risks.

Risk mitigation can beproactive or reactive. In the case of a risk, a plan B may be formulated, which can be used as a fall-back in case the risk materializes—such a plan B is a reactive response. Sometimes risks are accepted and are an example of a risk response which is neither proactive nor reactive. Risks are accepted because of various reasons, as in a situation where the probability or impact of the risk is too low for a response. Acceptance can also be the case in a situation where the apprehension of secondary risks may deter the product owner from taking any action. The effort made by the Product Owner to reduce the probability or impact—or both—of the risk is an example of a proactive response to mitigating risks.

Risk communication is important because stakeholders have an interest in the project and need to know the hindrances that the project may face. Information provided to stakeholders related to risk should include potential impact and the plans for responding to each risk. This communication is on-going and should occur in parallel with the four sequential steps discussed thus far—risk identification, assessment, prioritization and mitigation. The Scrum Team may also discuss specific risks related to their Tasks with the Scrum Master during Daily Standup Meetings. The Product Owner is responsible for the prioritization of risks and for communicating the prioritized list to the Scrum Team.

To know more please visit www.SCRUMstudy.com

Scalability of Scrum

Scalability of a process, network, or unit is its ability to adjust or adapt to any expansion. For example a central server is said to be scalable if it performs similarly when attending on either five clients or fifty clients. In Scrum, it means that the scaling mechanisms applicable for a single Scrum Team can also be used for larger projects with multiple teams.

Is Scrum scalable? Initially, Agile authors believed that Agile methodologies including Scrum was predominantly for small scale projects. This opinion was based on the fact that Scrum had not yet been applied on large scale projects. The Guide to the Scrum Body of Knowledge (SBOK™ Guide) gives comprehensive directions through which Agile methodologies including Scrum, can be scaled and applied on larger projects

When to scale? In small Scrum projects there is adequate scope for the self-organizing Scrum Team members to collaborate among themselves. The problem starts when team size expands and when there is coordination required between multiple teams. Scalability in Scrum can occur at three levels – Projects, Programs and Portfolios

How to scale? Scalability in Scrum is achieved primarily through the Scrum of Scrum (SoS) Meetings. Scrum recommends small teams; however if teams are larger it is recommended that they are divided into smaller teams who can meet occasionally to discuss their status.

What makes Scrum scalable? It is recommended that Scrum Teams should ideally have six to ten members. This does not mean that Scrum can be used only in small projects – it can be scaled to be used effectively in larger projects. If the size of the Scrum Team exceeds ten members, then multiple teams can be formed to work on the project simultaneously.

Scrum of Scrums facilitates synchronization between multiple Scrum Teams in larger projects. Team representatives update each other about team’s progress, challenges faced and coordination activities. Frequency of Scrum of Scrums (SoS) Meetings is determined by inter-team dependency, size of the project, recommendations by Scrum Guidance Body (SGB) and complexity level.

Scaling in Distributed Teams:

Scrum recommends collocated teams and face-to-face communication between team members. This is often not possible, as companies have distributed teams working in parallel across geographies and time zones. For the purpose of scaling, in larger projects employing distributed teams, the Scrum of Scrum Meeting can be held using video conferencing, chats, social media etc.

The ‘Convene Scrum of Scrums’ Process is facilitated by the Chief Scrum Master (or another Scrum Master). Representatives of various teams, usually the Scrum Master of individual teams or any other designated team member. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. In larger projects, as it is difficult to have all participants together at one time, all important matters should be discussed

The Scrum of Scrums meeting is usually held at predetermined intervals or when required, to collaborate and track progress, address impediments and dependencies across projects. An agenda for the meeting can be announced in advance by the Chief Scrum Master, allowing individual teams to consider the items for discussion. Impediments faced by individual teams, likely to affect other teams should also be indicated. Issues, risks and changes likely to affect multiple teams should also be communicated during this meeting.

Achieving Scalability:

Each team representative is expected to update other teams, usually in the form of four questions. (i) What has my team been working on since the last meeting?, (ii) What will my team do until the next meeting?, (iii) What were other teams counting on our team to finish that remains undone?, (iv) What is our team planning on doing that might affect other teams?

Result of Scrum of Scrums Meetings include Better Team Coordination facilitated coordination of work across multiple Scrum Teams, especially when there are tasks involving inter-team dependencies (as future tasks of one team may depend on the timely delivery of a task by another team). Discrepancies between work and deliverables are quickly exposed. The Scrum of Scrums is a forum where team members can transparently discuss issues and resolve them.

Scrum of Scrum of Scrums: In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums Meeting can be scaled up another level to a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

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 improvement

The 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

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 with slow and cluttered websites.

To know more please www.SCRUMstudy.com

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s)

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s) is crucial to the success of any project. In some projects, there may have been pre-conditions stipulating certain team members and their roles.

When there is flexibility in choosing the Scrum Master(s), the following are important Selection Criteria:

• Problem-solving skills—This is one of the primary criteria to be considered while selecting Scrum Master(s). The Scrum Master(s) should have the necessary skills and experience to help remove any impediments for the Scrum Team.
• Availability—The Scrum Master should be available to schedule, oversee, and facilitate various meetings, including the Release Planning Meeting, Daily Standup Meeting, and other Sprint-related meetings.
• Commitment—The Scrum Master should be highly committed to ensure that the Scrum Team is provided with a conducive work environment to ensure successful delivery of Scrum projects.
• Servant Leadership Style—Servant leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role

When identifying the Stakeholder(s), it is important to remember that stakeholders are all the customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master, and Scrum Team to provide inputs and facilitate creation of the project’s products. The stakeholders influence the project throughout its lifecycle.

To know more please visit www.SCRUMstudy.com

Risk Burndown Chart

In Scrum, the risk management activities are divided among various roles with some responsibility resting with everyone in the Scrum Team and the Scrum Master facilitating the process. Risk management is integral to ensuring value creation; therefore, risk management activities are performed throughout the project lifecycle and not just during project initiation.

Each risk could be assessed using different Risk Assessment tools. However, the preferred tool for assessing risks to create a Risk Burndown Chart is Expected Monetary Value (EMV).

The information gathered during risk assessment may be used to create a Risk Burndown Chart. This depicts cumulative project risk severity over time. The likelihoods of the various Risks are plotted on top of each other to show cumulative risk on the y-axis. The initial identification and evaluation of risks on the project and the creation of the Risk Burndown Chart are done initially. Then, at predetermined time intervals, new risks may be identified and assessed and remaining risks should be re-evaluated and updated accordingly on the chart. An appropriate time to do this is during the Sprint Planning Meeting. Tracking risks in this manner allows the team to recognize trends in risk exposure and take appropriate action, as necessary.

To know more please visit www.SCRUMstudy.com

Implementing Scrum in Organizations

Scrum is not your regular waterfall technique but an agile framework which changes and, at times, challenges traditional roles. The Organizational Resource Matrix is a hierarchical depiction of a combination of a functional organizational structure and a projectized organizational structure. Matrix organizations bring together team members for a project from different functional departments such as information technology, finance, marketing, sales, manufacturing, and other departments – and create cross-functional teams. Managers, developers, and testers will be assigned the roles of the Product Owner, the Scrum Master, and the Development Team (Scrum Team).

The Skills Requirement Matrix, also known as a competency framework, is used to assess skill gaps and training requirements for team members. A skills matrix maps the skills, capabilities, and interest level of team members in using those skills and capabilities on a project. Using this matrix, the organization can assess any skill gaps in team members and identify the employees who will need further training in a particular area or competency. Team members may not always possess the required knowledge or skills to work in the Scrum environment. The Product Owner should evaluate the training needs of potential team members and facilitate training to bridge any knowledge gaps in the team.

The Product Owner is normally responsible for evaluating and selecting team members, but often does this in consultation with the Scrum Master who may have additional knowledge of the resources from working with them on other projects. Appropriate training should be provided to the Scrum Team members both prior to the commencement of work, and also when they are working on their projects. Scrum Team members should also be ready to learn from each other and from more experienced persons in the team. The awareness level of Scrum in an organization needs to be assessed which will help probe into the readiness of an organization and its people for Scrum.

There are different aspects of an organization that needs to be gauged: organizational, infrastructural, business, team, technological, and procedural. The results of the assessment will allow for a more specific awareness generation or training in the area concerned.  Product Managers, Project Managers, Functional / Departmental Managers, Scrum Team Members (including Architects, Designers, Coders, Testers, and others), and Executives in organizations doing Scrum must be provided with the right level of insight into Scrum for its successful implementation. Insight should not just be provided to the core roles (Product Owner, Scrum Master, and Scrum Team) but should also extend to the non-core roles (Users, Stakeholders, Consulting Experts, and Management).

Creating a good cooperation and continuous exchange of information between these two roles is crucial to the success of a project. The non-core roles have to be actively involved in envisioning the product and providing feedback as to “what” should constitute the desired product. The Scrum Team and the Product Owner should be left to figure out the “how” of achieving the desired results.  Changed to Scrum team. Therefore, the Scrum Team must be trained to actively seek feedback from the Product Owner who funnels the feedback from the other non-core roles, and those stakeholders must be sensitized well in the practices of Scrum so that they do not interfere with the workings of the Scrum Team.

For a well-developed Scrum implementation in an organization, the level of awareness about Agile principles and values must be extensive. The Scrum Team has to be sensitized and trained in the ways of Scrum and the Scrum Master should act like a coach. The Scrum Master needs to bring out the best from the Scrum team by motivating them and facilitating the development process. Apart from the Scrum Team, the Product Owner also needs to be trained well.  The Product Owner is the bridge between requirements and development. The more he/she is able to understand the requirements the better product development will be.

Implementation of Scrum changes not just the development team or a few management executives associated with a team or a project but at every level of the organization. Change at an organizational level is complex and is influenced by various factors: the culture of an organization, insecurity of managers, employee resistance, failure to see the need for change, fear of the unknown. These hurdles need to be addressed professionally by the Scrum Master. Clear objectives need to be communicated to all personnel about the implementation of Scrum.

To know more please visit www.SCRUMstudy.com