How is Change management embedded into the Scrum Framework?

How is Change management embedded into the Scrum Framework?

Depending on the industry and type of project, the priority of features and requirements for a

project may remain fixed for significant durations of time, or they may change frequently. If project

requirements are generally stable, there are typically only minor changes made to the Prioritized

Product Backlog throughout development, and Scrum Teams can work sequentially completing

requirements that will provide maximum customer value as prioritized in the Prioritized Product

Backlog. The length of the Sprint is usually longer, 4 to 6 weeks, in such stable environments.

If project requirements change throughout the project, for example due to changed business

requirements, the same method continues to be effective. Before beginning a Sprint—during the

Create Prioritized Product Backlog or Groom Prioritized Product Backlog processes—the highest

priority requirements in the Prioritized Product Backlog are typically selected to be completed in

that Sprint. Because changes have been accounted for in the Prioritized Product Backlog, the team

only needs to determine how many tasks they can accomplish in the Sprint based on time and

resources provided. Change management is executed in the ongoing processes of prioritizing and

adding tasks to the Prioritized Product Backlog.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product

Owner, after consultation with relevant stakeholders, decides whether the change can wait until

the next Sprint or represents an urgent situation which may require ending the current Sprint and

starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint

begins. If the required change is so important that the results of the Sprint would be worthless

without it, then the Sprint should be terminated. If not, then the change is incorporated into a later

Sprint.

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint

begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and

has spare capacity to implement additional User Stories, the team can ask the Product Owner which

additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their

work and effort. An additional benefit is that the team does not have to worry about managing

changes once they start working on a Sprint. This is a big advantage of the Scrum framework when

compared to traditional project management.

Because changes are not allowed during a Sprint, the impact and frequency of expected changes

may have an impact on the decision related to the length of the Sprint when it is determined during

the Conduct Release Planning process.

If project requirements are generally stable and major changes are not expected in the near future,

the Length of a Sprint may be set to be longer, 4 to 6 weeks. This provides stability to the Scrum

Team members to work on the Prioritized Product Backlog requirements for lengthy periods of time

without having to go through the Create User Stories, Approve, Estimate and Commit User Stories,

Create Tasks, Estimate Task, and other related processes that are conducted for every Sprint.

However, if project requirements are not very well defined or if significant changes are expected

in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks. This provides

stability to the Scrum Team members to work on shorter Sprints and deliver results, which can

be evaluated by the Product Owner and stakeholders at the end of the Sprint. This also provides

enough flexibility for them to clarify requirements and make changes to the Prioritized Product

Backlog at the end of each Sprint.

To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-
boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend

up to 6 weeks.

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.

One of the Product Owner’s key responsibilities is grooming the Prioritized Product Backlog. To

ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next

two to three Sprints are refined into suitable User Stories, it is recommended that the Product

Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog

grooming. The Product Owner is responsible for adding and revising Prioritized Product Backlog

Items in response to any changes and is responsible for providing more detailed User Stories that

will be used for the next Sprint.

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-analyzed and clearly defined set of

stories that can be easily broken down into tasks and subsequently estimated. Grooming supports

and enhances the flexibility of the Scrum model by incorporating the latest business and technical

insights into future Sprints.

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during

Groom Prioritized Product Backlog process.

Although the Stakeholder(s) and the Product Owner have the final say on Prioritized Product

Backlog Items and whether to accept or reject any Change Requests presented during Demonstrate

and Validate Sprint, it is the Scrum Master’s responsibility to ensure that the requirements and

Acceptance Criteria are not altered during the Sprint Review Meeting for the User Stories completed

in the current Sprint. This prevents the rejection of completed User Stories based on the fact that

they do not meet newly changed requirements. If any requirements need to be changed, any

corresponding PBI needs to be revised to accommodate the modified requirements in a future

Sprint.

What is Crystal?

What is the “Crystal methodology”?

Introduced by Alistair Cockburn, Crystal Methods, which is a collection of Agile software development approaches, focuses primarily on people and the interaction among them while they work on a software development project. There is also a focus on business-criticality and business-priority of the system under development. Unlike traditional development methods, Crystal doesn’t fix the tools and techniques of development, but keeps people and processes at the core of the development process. However, it is not only the people or the processes that are important, rather the interaction between the two that is most important.

In Cockburn’s words, “Crystal is a family of human-powered, adaptive, ultra light, ‘stretch-to-fit’ software development methodologies.” (Alistair Cockburn;http://alistair.cockburn.us/Crystal+methodologies.)

So, what does “human-powered, adaptive, ultra light, ‘stretch-to-fit’” mean?

• Crystal is “human-powered”—This means that people are the most important aspect of Crystal, and all the processes and tools are relative to them. Crystal believes that software development is essentially a human activity, so people involved in this activity are vital while the processes should be modelled to meet the requirements of the team, not the other way around. Crystal emphasizes that development teams are self-sufficient and self-organizing, so they are capable of streamlining the processes as the development process progresses and become more organized and competent.
• Crystal is “adaptive”—First of all, it should be remembered that Crystal is not a set of prescribed tools and techniques for software development; rather, it is an approach. So, the processes and tools are not fixed, but have to be adjusted to the requirements  and characteristics of the project. In other words, Crystal is a “stretch-to-fit” methodology, because each project is unique and require methods that suit the business requirements and that satisfy the technical requirements of the project.
• Crystal is “ultra light”—Crystal is known as a “lightweight methodology.” This is because Crystal doesn’t advocate too much documentation, overhead management and reporting. Instead, it believes in keeping things light and focusing on developing business-valued and functional software. For this, teams following the Crystal approach work toward enhancing free and open communication among  team members as well as establishing transparent flow of information between developers and stakeholders.

How does Crystal operate?

As stated above, Crystal is not a set of prescribed development tools and methods, but a family of various development approaches. At the beginning of the project, the processes and tools are not fixed but are decided by considering the business requirements and technical needs of the project. When deciding whether Crystal is the right methodology for a project, consider comfort, discretionary money, essential money and life along with the size of the team working on a particular project. Various methodologies in the Crystal family are known as the various “weights” of the Crystal approach and are represented by different colors of the spectrum.

Therefore, the Crystal family of methodologies consists of the following variants: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond and Crystal Sapphire

To clarify, Crystal Clear is more appropriate for comparatively short-term projects being managed by a team of six developers working out of a single workspace, whereas Crystal Orange is suited for projects that require a team of 10 to 40 members and have a lifespan of 1-2 years. On the other hand, Crystal Sapphire or Crystal Diamond methods are used in large projects that involve potential risk to human life. Therefore, the weight of the Crystal methodology is determined by the project environment and the team size.

What are the main practices recommended by Crystal?

Crystal is precise about certain practices because these are crucial for the successful implementation of the Crystal approach onto any project. These practices include:

• An iterative and incremental development approach—The projectis developed in iterations that are generally time boxed. The feature delivered at the end of an iteration is integrated into the overall system. User feedback taken at the end of an iteration is used to plan the next iteration; and, new and additional features are added in every subsequent iteration. All this results in refinement and completion of the overall software.
• Active user involvement—This is a must because Crystal is a people-centric approach and emphasizes transparency. So, users are not only actively involved but also regularly informed about the progress of the project.
• Delivering on commitments—The team endeavors to ensure frequent delivery of client-valued, potentially-shippable functionalities. It is to this end that Crystal follows an iterative and an incremental development approach.

What are the roles prescribed by Crystal?

The Crystal approach defines a number of roles: Project Sponsor, Senior Designer/Programmer, Designer/Programmers (Business Class Designers, Programmers, Software Documenters and Unit Testers) and Users. Also, there are a number of other roles such as Architect, Coordinator, Requirements Gatherer, Business Expert, Business Analyst/Designer, Project Manager, Design Mentor, Usage Expert, Lead Design Programmer, UI designer, Technical Facilitator and Technical Writer.

Integrating Scrum and Kanban

Scrum and Kanban are the offspring of the agile methodology. The two methods may have different approaches, but are both rooted in the agile philosophy of software development. Scrum is useful in projects in which there will be periodic releases and Kanban comes handy in projects in which there will be frequent releases. Scrum is most often used for projects related to product development. Kanban is a useful visual project management tool and is helpful for production support. Now, when both these processes are combined, we get an upgraded process known as Scrumban, which encompasses the best practices of Scrum and Kanban. Scrumban is an enhanced and improved Scrum process.

Before we discuss how Scrum and Kanban are integrated in the Scrumban process, will have a quick look at some of the salient features of scrum and Kanban.
Implementing Scrum means:

• Breaking the entire organization into cross-functional several teams
• Breaking down the entire project into small chunks of well-defined deliverables
• Listing the chunks in terms of priority and estimating the amount of work required to complete each one of them
• Splitting time into short periods (iterations) where market-ready code is presented
• Working on the release plan based on the review and feedback after the iteration
• Enhancing the process with the help of retrospection after the iteration

Speaking of the workflow in scrum, the team plans and decides on the work that it will be completed in the upcoming sprint. Once decided, the sprint activities are finalized and are finished within the sprint duration, clearing the queue.

Now we will look at the features of Kanban:

• Breaking down work into items, writing each item on a card and then sticking it on a wall
• Using designated columns to show the placement of each item in the workflow
• Limiting the work in progress by allocating clear limits on the number of items that may be in progress at each workflow level
• Measuring the time needed to complete an item and trying to the lead time as predictable as possible

When it comes to the Kanban workflow, the limit on work in progress enables the team to change items in queues whenever it is needed. There’s no clearing the queue, and there is a continuous flow of work.

How are Scrum and Kanban integrated as Scrumban?

As a process, Scrumban employs the scrum principles. But along with it, it integrates Kanban tools for process improvement. Despite being used in different kinds of projects, the mechanics of Scrum and Kanban are compatible with each other. The addition of WIP limit and visual workflow to Scrum ensures that the process undergoes continuous improvement. The whole idea of planning in Scrumban is to fill vacant slots—if there is no item in a slot, then the vacancy will be filled with iteration planning. This results in decreasing the overhead of iteration planning. In a nutshell, Scrumban is Scrum in practice and Kanban in culture.

Integrating the two agile processes leads to several advantages in terms of quality, just-in-time delivery, short lead time, continuous improvement (also known as Kaizen in Kanban terminology), reducing waste and overall process improvement.

Though Scrumban is a relatively new approach in agile, it is gaining quite a lot of popularity and attention from industries that have to cater to both development and maintenance work.
Here are some areas where Scrumban can be implanted in order to achieve success:

• Projects related to maintenance
• Projects that require event -driven work
• Projects that are prone to programming errors
• Teams created to mainly work on developing new products

How will SCRUM benefit me?

Scrum is a hugely beneficial approach to managing software development projects; however, for the team to be successful it must adhere to the core values and principles enshrined in the Agile Manifesto. If Scrum processes are followed properly, then the team will experience the “Enabling Eight.”

1. The team is more likely to produce functional, high-quality software, because the team’s aim is to deliver working software and not just to complete the development activity.
2. An iterative and incremental development approach will enable the team to better cope with the changes that occur when modifications are demanded by stakeholders as the project progresses.
3. Less documentation will enable the team focus more on developing software than on maintaining records.
4. Frequent Sprint reviews as well as practices such as the Product Backlog, DailyScrum Meetings and Burn-down charts enhance greater visibility and transparency of progress and reduce risks.
5. Regular feedback from the customer will help the development team refine the software by incorporating the suggested changes and delivering high-quality software.
6. Close, face-to-face communication among team members will boost cooperation resulting in better teamwork and in increased productivity.
7. A change-oriented approach will help the team to inspect and adapt the important features, thereby evolving the overall product as the development process proceeds.

Regular Sprint reviews as well as practices such as burn down andvelocity will enhance customer satisfaction, which is crucial to any software development activity.

Scrum : Responsibilities of a Product Owner in a Scrum Project

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. Scrum roles fall into two broad categories, namely, core roles and non-core roles. There are three core roles in Scrum that are ultimately responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others. Now, let us look at the Product Owner role in detail.

The Product Owner represents the interests of the stakeholder community to the Scrum Team and is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner, thus, ensures clear communication of product or service functionality requirements to the Scrum Team, defining Acceptance Criteria, and ensuring those criteria are met. In other words, the Product Owner is responsible for ensuring that the Scrum Team delivers value. The Product Owner must always maintain a dual view.

The Product Owner must understand and support the needs and interests of all stakeholders, while also understanding the needs and workings of the Scrum Team. Because the Product Owner must understand the needs and priorities of the stakeholders, including customers and users, this role is commonly referred to as the Voice of the Customer. Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

Before we check out some of the key responsibilities of a Product Owner, here is a video on the Product Owner role:http://www.scrumstudy.com/watch.asp?vid=455.

The key responsibilities of a Product Owner in relation to a Scrum Project are:

• Defines the Project Vision and helps create the Project Charter and Project Budget
• Helps finalize Scrum Master for the project and identifies Stakeholder(s)
• Helps determine Scrum Team members and helps develop a Collaboration Plan
• Helps develop the Team Building Plan with Scrum Master(s)
• Creates Epic(s) and Personas and prioritizes Prioritized Product Backlog Items
• Defines Done Criteria and creates Release Planning Schedule
• Helps determine Length of Sprint along with helping creation of User Stories
• Defines Acceptance Criteria for every User Story and approves the created User Stories
• Facilitates Scrum Team and commit User Stories
• Explains User Stories to the Scrum Team while creating the Task List
• Provides guidance and clarification to the Scrum Team in estimating effort for tasks
• Clarifies requirements to the Scrum Team while creating the Sprint Backlog
• Clarifies business requirements to the Scrum Team
• Grooms the Prioritized Product Backlog and accepts/rejects Deliverables
• Provides necessary feedback to Scrum Master and Scrum Teams
• Updates Release Plan and Prioritized Product Backlog
• Helps deploy Product Releases and coordinates this with the customer
• Participates in Retrospective Sprint Meetings

Scrum : Responsibilities of a Product Owner in a Scrum Project

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. Scrum roles fall into two broad categories, namely, core roles and non-core roles. There are three core roles in Scrum that are ultimately responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others. Now, let us look at the Product Owner role in detail.

The Product Owner represents the interests of the stakeholder community to the Scrum Team and is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner, thus, ensures clear communication of product or service functionality requirements to the Scrum Team, defining Acceptance Criteria, and ensuring those criteria are met. In other words, the Product Owner is responsible for ensuring that the Scrum Team delivers value. The Product Owner must always maintain a dual view.

The Product Owner must understand and support the needs and interests of all stakeholders, while also understanding the needs and workings of the Scrum Team. Because the Product Owner must understand the needs and priorities of the stakeholders, including customers and users, this role is commonly referred to as the Voice of the Customer. Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

Before we check out some of the key responsibilities of a Product Owner, here is a video on the Product Owner role:http://www.scrumstudy.com/watch.asp?vid=455.

The key responsibilities of a Product Owner in relation to a Scrum Project are:

• Defines the Project Vision and helps create the Project Charter and Project Budget
• Helps finalize Scrum Master for the project and identifies Stakeholder(s)
• Helps determine Scrum Team members and helps develop a Collaboration Plan
• Helps develop the Team Building Plan with Scrum Master(s)
• Creates Epic(s) and Personas and prioritizes Prioritized Product Backlog Items
• Defines Done Criteria and creates Release Planning Schedule
• Helps determine Length of Sprint along with helping creation of User Stories
• Defines Acceptance Criteria for every User Story and approves the created User Stories
• Facilitates Scrum Team and commit User Stories
• Explains User Stories to the Scrum Team while creating the Task List
• Provides guidance and clarification to the Scrum Team in estimating effort for tasks
• Clarifies requirements to the Scrum Team while creating the Sprint Backlog
• Clarifies business requirements to the Scrum Team
• Grooms the Prioritized Product Backlog and accepts/rejects Deliverables
• Provides necessary feedback to Scrum Master and Scrum Teams
• Updates Release Plan and Prioritized Product Backlog
• Helps deploy Product Releases and coordinates this with the customer
• Participates in Retrospective Sprint Meetings

What are the important roles in Scrum project?

Isn’t it important that each person working in a scrum project know exactly what he/she should do?  Undoubtedly, yes.   There should be a clear understanding of defined roles and responsibilities to ensure the successful implementation of Scrum projects.

Scrum roles fall into two broad categories, Core Roles and Non-core-roles.

Core Roles—Core roles are those roles which are mandatorily required for producing the product of the project, are committed to the project, and ultimately are responsible for the success of each Sprint of the project and of the project as a whole.

There are three core roles in Scrum that are ultimately responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

Product Owner

The Product Owner is the person responsible for maximizing business value for the project. He/she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.

Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

Scrum Master

The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the product’s development successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.

The Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management, in which the Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he/she is at the same hierarchical level as anyone else in the Scrum Team—any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.

Corresponding to a Scrum Master role in a project, there could be a Program Scrum Master for a program or a Portfolio Scrum Master for a portfolio.

 

Scrum Team

The Scrum 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.

The Figure given below presents an overview of the Core Scrum Team roles.

Scrum Roles—Overview

Non-core Roles—Non-core roles are those roles which are not mandatorily required for the Scrum project, and may include team members who are interested in the project, have no formal role on the project team, may interface with the team, but may not be responsible for the success of the project. The non-core roles should also be taken into account in any Scrum project.

The non-core roles are those roles which may not be continuously or directly involved in the Scrum process. However, knowing non-core roles is important as they could play a significant part in some Scrum projects.

Non-core roles can include the following:

Stakeholder(s)

Stakeholder(s) is a collective term that includes customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master and Scrum Team to provide them with inputs and facilitate creation of the project’s product, service, or other result. Stakeholder(s) influence the project throughout the project’s development. Stakeholders may also have a role to play during Develop Epic(s), Create Prioritized Product Backlog, Conduct Release Planning, Retrospect Sprint and other important processes in Scrum.

Customer 

The customer is the individual or the organization that acquires the project’s product, service, or other result. For any organization, depending on the project, there can be both internal customers (i.e., within the same organization) or external customers (i.e., outside of the organization).

Users

Users are the individual or the organization that directly uses the project’s product, service, or other result. Like customers, for any organization, there can be both internal and external users. Also, in some industries customers and users may be the same.

Sponsor

The sponsor is the individual or the organization that provides resources and support for the project. The sponsor is also the stakeholder to whom everyone is accountable in the end.

Vendors

Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization.

At times, the same person or organization can play multiple stakeholder roles; for example, the sponsor and the customer may be the same.

Scrum Guidance Body

The Scrum Guidance Body (SGB) is an optional role. It generally consists of a group of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. These objectives guide the work carried out by the Product Owner, Scrum Master, and Scrum Team. The Scrum Guidance Body also helps capture the best practices that should be used across all Scrum projects in the organization.

The Scrum Guidance Body does not make decisions related to the project. Instead it acts as a consulting or guidance structure for all the hierarchy levels in the project organization—the portfolio, program, and project. Scrum Teams have the option of asking theScrum Guidance Body for advice as required.

These are important roles necessary for the successful implementation of a Scrum project.

Scrum : Tools and Techniques for Estimating Tasks in a Scrum Project

The Scrum Core Team uses various tools and techniques such as Task Estimation Meetings, Estimation Criteria, Planning Poker, Fist of Five, etc. to estimate the effort required to accomplish each task in the Task List. When estimating tasks, the core team create the Effort Estimated Task List which is a list of tasks associated with the Committed User Stories included in the ensuing Sprint. Now, let us analyze some of the important tools used by the Scrum Core Team to estimate tasks. Here is an introductory video on estimating tasks:http://www.scrumstudy.com/watch.asp?vid=614

The first tool or technique is the Task Estimation Meeting. This meeting enables the Scrum Team to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. In Task Estimation Meetings, the Scrum Team members use the Task List to estimate the duration and effort for the User Stories to be completed in the Sprint.

One of the key benefits of this technique is that it enables the team to have a shared perspective of the User Stories and requirements so that they can reliably estimate the effort required. The information developed in the Task Estimation Meetings is included in the Effort Estimated Task List and it is used to determine the velocity for the Sprint. In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. Task Estimation Meetings are sometimes also referred to as “Sprint Planning Meetings” – such meetings may also be combined with Task Planning Meetings.

Next is Estimation Criteria. The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being story points and ideal time. For example, an ideal time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s deliverables, without including any time spent on other activities or work that is outside the project. Estimation Criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.

Planning Poker is another technique that can be used to estimate tasks. Planning Poker, also called Estimation Poker, is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them. In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent complexity of the problem, in terms of time or effort, as estimated by the team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it. Then, each member picks a card from the deck that represents their estimate for the User Story. If the majority or all team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached. Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of group think.

Another technique that can be used in this regard is Fist of Five. Fist of Five is a simple and fast mechanism to achieve consensus in a group and drive discussion. After initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building but also driving discussion because each team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the team has discussed it, a collective decision will be made. The number of fingers used to vote indicates the level of agreement and desire for discussion:

1. One finger: I disagree with the group’s conclusion and have major concerns.
2. Two fingers: I disagree with the group’s conclusion and would like to discuss some minor issues.
3. Three fingers: I am not sure and would like to go with the group’s consensus conclusion.
4. Four fingers: I agree with the group’s conclusion and would like to discuss some minor issues.

Five fingers: I wholeheartedly agree with the group’s conclusion.

SCRUM : Definition of Quality in Scrum

There are numerous ways to define quality. In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, 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.

The Prioritized Product Backlog is simply never complete until the closure or termination of the project. 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 repetitive quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint.

Thus, 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) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Here is a video on how Scrum defines quality:http://www.scrumstudy.com/watch.asp?vid=524

Now, let us look at how quality is linked with scope, business value and other aspects or elements of a project. The scope of a project is the total sum of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog, and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provides the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

Scrum: Core and Non-core Roles

Central to the success of a Scrum project are the people or employees working on the project, and coordination between them. To ensure coordination and harmony within the scrum team, it is necessary to clearly define the roles and responsibilities of the Scrum team members.

The roles in scrum teams fall into 2 major categories – Core Roles and Non-core roles. These categories are defined clearly in the SBOK Guide published by SCRUMstudy.  The basis of this classification is the impact of these roles on the success of a Scrum Project.

Scrum Core Roles have direct impact on the success of a project. These roles are held responsible for the production of deliverables in each sprint which meet the acceptance criteria and in turn success of the entire project. These roles have formal roles to perform in a scrum team.

Scrum Non-core Roles does not have direct impact on the success of the project but they have interest in the project and its outcome. These roles are not held responsible for the failure of the sprint or the project as a whole. As they are interested in the project outcome, it is required to consider their view in the projects.  Each of these roles is further classified as mentioned below.

Core Roles:

• Product Owner – Project Owner represents the voice of a customer. He is responsible to understand the customer requirements and articulate the same to the scrum team. He is also responsible to deliver maximum business value to the customer. He defines the acceptance criteria for the deliverables.
• Scrum Master – Scrum Master is responsible for removing the impediments faced by the scrum team members and facilitate the team in developing the deliverables. He also sees to it that the team is working in harmony and work towards attaining the defined goals.
• Scrum Team/ Development Team – Scrum team or the Development team is responsible for the production of goods and services that meet the acceptance criteria. The scrum team is responsible for the success or failure of the project as it is directly involved in the production.

Non-core roles:

• Stakeholders – Customers, Users, Sponsors are the stakeholders in the scrum project who have interest in the outcome of the project but are not directly involved in the sprints for productions.
• Vendors – Vendors or the suppliers are the one who deliver the semi-finished products that go into the final production of the deliverable by the scrum team.
• Scrum Guidance Body –  As defined in the SBOK Guide, scum guidance body is a group of people of set of documents that define the quality criteria, government rules and regulations, etc. that affect the performance of the scrum team.

The above discussed core and non-core roles in scrum projects are responsible directly or indirectly for the success of a sprint and the deliverables of each sprint. Hence, it is necessary to understand each of these roles and define their responsibilities and authority.