SCRUMstudy @scrumstudy - Tumblr Blog

Four Tools for Fantastic Project Vision Creation

Question: What’s a camel?

Answer: A horse designed by a committee.

Sometimes a Project Vision Statement can become clumsy-looking and all-inclusive like a camel, when what was needed is a sleek, powerful racehorse. Using the right tools skillfully can keep your Project Vision Statement thoroughbred thin.

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 learn more about the changing trends in the world of Scrum and Agile, visit SCRUMstudy.

Delivering Hybrid IT Value

The “hybrid cloud may be garnering increased interest and adoption, but it is already giving way to new terms such as hybrid IT and hybrid enterprise,” writes Eileen Yu on ZDNET. Hybrid IT? Where have we heard this term before?

In 2014, Computerworld.com predicted that businesses would need to fill one or more of five hybrid-IT roles in order to succeed. “It’s clear that the 2014 corporate agenda will be dominated by the integration of big data analytics, cloud computing, mobile technology, and social media into the enterprise,” wrote Stephanie Overby in Computerworld New Zealand. She adds, “The differentiator will not be the technology itself, but the business value it delivers.”

It seems that hybrid IT is still here two years later, growing bigger in the cloud, and still focused on business value.

Delivering value is not new to Agile- and Scrum-certified professionals. What continues to be new is the emphasis. Overby wrote, “It won’t be about the ability to simply configure and run a server. Or develop software in isolation. Context will be king.” She says, “Employers will aggressively pursue workers with multi-dimensional talent—combinations of technology, domain, business, process, and people skills, orchestrated in a proper balance to deliver specific solutions.”

Writing for Computerworld’s American online magazine, Patrick Thibodeau put this another way back in 2014: “Employers want workers who understand the business and technology. This trend is increasing the mix of requirements to get an IT job. [One industry expert] estimates that by 2017, 50% of the IT roles will require business knowledge.” The growing adoption of the hybrid cloud indicates that this trend is still active.

The hybrid roles Overby discusses include “enterprise architects who get the cloud,” “security professionals with marketing skills” and “software engineers that do more than generate code.” The question of where to find these people becomes important, as does the question of how to provide a work environment in which these employees succeed.

IT professionals who already fit one or more of the hybrid roles may already exist, but how is a company going to find that coding pro who can use his or her business sense to “bring structure to unstructured” collections of meta-data? One place to look is for individuals with Scrum experience.

A thoughtful look at this trend as it continues through 2017 reveals that Scrum can provide what savvy corporations and IT professionals need.

Scrum uses cross-functional teams in which “team members are generalist/specialists in that they have knowledge of various fields and are experts in at least one,” according to A Guide to the Scrum Body of Knowledge (SBOK™) by SCRUMstudy. Scrum Teams are also self-organizing and “beyond their subject-matter expertise, it is the soft skills of team members that determine the success of self-organizing teams,” says the SBOK™ Guide. This matches closely with the “multi-dimensional talent — combinations of technology . . . and people skills” listed by Overby.

As each increment of the service, product or desired result is demonstrated by the Scrum Team to the Product Owner and customers, each team member develops a keen business sense and orientation. At any point in the development process, the Scrum Team member is able to articulate the business value of the particular task he or she is producing.

As part of a self-organizing team, Scrum Team members take ownership of the processes and schedules needed to complete their project. They develop domain and process skills that, as Overby says, are “orchestrated in a proper balance to deliver specific solutions.”

As a part of a cross-functional team, each member commits to backing up other workers. While being an expert in an area needed for the project, each worker will also learn an area in which another team member is the expert. The aim here is to be able to substitute for that person in those cases when a team member is not present.

Companies do not have to go searching for individual professionals with hybrid talents; they can “breed” their own. With the implementation of Scrum in the workplace, its processes and best practices will begin to develop cross-functionality within the organization and within individuals right away. While members of cross-functional teams will be learning from each other and expanding their skills and knowledge sets, the company will have the benefit of hybrid talent being supplied by the team as a whole.

Scrum Teams are “able to foster an environment of independent thinking and group decision-making in order to extract the most benefits from the structure,” according to the SBOK™ Guide. While Scrum is helping some employees become “security professionals with marketing skills,” Scrum Teams with both types of professionals provide that integration of skills and understanding immediately.

Accrediting organizations such as SCRUMstudy can put both companies and professionals in touch with professional training providers that specialize in Scrum and Agile.

As hybrid IT becomes an increasingly important part of hybrid cloud enterprises, companies using Scrum will soar.

Works Cited

A Guide to the Scrum Body of Knowledge (SBOK™ Guide). http://www.scrumstudy.com/overview-of-sbok.asp

Importance of Sprint Backlog in a Scrum Project

What is a Sprint Backlog? Is it a baseline, a record or a report? Baseline is a project document, which, defines aspects of the project and, once approved, is subject to change control. It is used to measure project’s actual performance as against planned targets. A record maintains information on the progress of the project. A report provides snapshots of the status of different aspects of a project at a given point of time or for a given duration.

To answer this question, we need to understand what a Sprint Backlog is, its purpose and composition. The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during Sprint Planning Meeting. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed during the Approve, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.

It is common practice in Scrum that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

Another tool associated with the Sprint Backlog is the Sprint Burndown Chart. It is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

So, it is difficult to categorize the Sprint Backlog as a baseline, record or a report. And as Scrum professes minimum documentation, Sprint Backlog fulfills purposes of more than one project document. For more information on Scrum framework, you can read the Scrum Body of Knowledge (SBOK Guide). It can be downloaded for free in SCRUMstudy website:http://www.scrumstudy.com/download-free-buy-SBOK.asp

Quality Planning and Technical Debt

Developing functionality of highest priority to the customer at first is one of the major principles of Scrum. This approach allows the Scrum team to focus keenly on the quality planning as they get the required time to categorize the essential functionality according to the customer’s requirements.

What is Technical debt?

The technical debt, which is also referred to as code debt or design debt, which refers to work that the Scrum teams prioritize lower, omits, or do not complete as they work toward creating the primary deliverable. Technical debt is a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release.

Why does Technical debt occur?

The technical debt increases over time and must be paid in the future. Here are some of the key reasons for technical debt to occur:

Quick-fix and building deliverable that do not comply with standards for quality, security, long-term architecture goals, etc.

Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful

Inadequate or incomplete testing

Poor sharing of business knowledge and process knowledge among the stakeholders and project teams

Improper or incomplete documentation

Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverable that incur significant maintenance and upgrade costs.

How to control/reduce the Technical debt?

Quality planning has one of its important benefits in terms of reducing the Technical debt. In order to maintain a minimal amount of technical debt it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.

Visit www.SCRUMstudy.com

Various Aspects of Scrum

Scrum is a framework for collaborative effort of the team on some of the very complex software projects. It is the most widely-used subset of Agile. The Scrum principles are the fundamental guidelines for applying Scrum framework. The Scrum framework drives on the goals of giving utmost business value in least time.

Various Scrum aspects are derived and are very essential to be addressed and managed throughout a Scrum project. Here are the five Scrum aspects as mentioned in theSBOK™ Guide

Organization: Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum. Scrum roles fall into two broad categories; Core Roles (which includes Product Owner, Scrum Master, Scrum Team) and Non-core Roles (which includes Stakeholder, Scrum Guidance Body, Vendors, Chief Product Owner, Chief Scrum Master)

Business Justification: Business justification in Scrum is based on the concept of Value-driven Delivery. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project.

Quality: 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. The Scrum Guidance Body may also provide guidelines about quality which may be relevant to all Scrum projects in the organization.

Change: Every project, regardless of its method or framework used, is exposed to change. Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables. This enables the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.

Risk: Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks should be identified, assessed, and responded to basing on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence.

SCRUMstudy certification courses offer a detailed description of all these Scrum aspects. Please visit www.scrumstudy.com for more details on SCRUMstudy certifications.

The story behind the 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 learn more about the changing trends in the world of scrum and agile, visit SCRUMstudy.

Understanding a Scrum Project

Recently Scrum has gained immense popularity and attention among the management and development methodologies. So let us see what a Scrum Project is all about.

A Scrum project involves a collaborative effort to create a new product, service, or other result as defined in the Project Vision Statement. Projects are impacted by constraints of time, cost, scope, quality, resources, organizational capabilities, and other limitations that make them difficult to plan, execute, manage, and ultimately succeed. However, successful implementation of the results of a finished project provides significant business benefits to an organization. It is therefore important for organizations to select and practice an appropriate project management methodology.

Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum framework, as defined in the SBOK™, is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity.

A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints. Figure 1-1 provides an overview of a Scrum project’s flow.

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholders are provided a demonstration of the Deliverables. The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

To learn more about the scrum projects, visit www.SCRUMstudy.com

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 #agile #project management

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 #agile #project management

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 #agile #project management

Scrum : Conflict Management Techniques Relevant to Scrum

Organizations applying the Scrum framework encourage an open environment and dialogue among employees. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside the Scrum Team.

Conflict can be healthy when it promotes team discussions and encourages debates, as this usually results in benefits for the project and the respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.

Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs. Usually there are four approaches to managing conflict in an organization applying Scrum processes:

· Win-Win

· Lose-Win

· Lose-Lose

· Win-Lose

Win-Win technique is usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes.

Next is Lose-Win. Some team members may at times feel that their contributions are not being recognized or valued by others, or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This approach is called Lose-Win. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders and/or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations. For example, it is important for all team members to speak and contribute at each Daily Standup Meeting so that any issues or impediments can be made known and managed effectively.

The next technique is Lose-Lose. In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. This generally results in an overall Lose-Lose outcome for the individuals involved and consequently the project. The Scrum Team should be careful to ensure that team members do not get into a Lose-Lose mentality. Scrum Daily Standup and other Scrum meetings are conducted to ensure that actual problems get solved through mutual discussions.

Finally, the Win-Lose technique. At times, a Scrum Master or another influential team member may believe he or she is a de facto leader or manager and try to exert their viewpoint at the expense of the viewpoints of others. This conflict management technique is often characterized by competitiveness and typically results in a Win-Lose outcome. This approach is not recommended when working on Scrum projects, because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker.

#SCRUM #AGILE #project management

Scrum : Important Roles in a Scrum Project

It has been proved by surveys that additional certifications such as ITIL, PRINCE2, PMP and Scrum can not only help a professional (IT or non-IT) gain more knowledge regarding success in their projects, but also help an organization in which he/she works in the long run. One of the most similar facts that can be seen from these certifications is that they all emphasize the importance of roles and non-roles in their projects. In this article, the emphasis is placed on roles and non-roles of an organization. In Scrum training or Scrum certification, a lot of time is dedicated to defining and understanding roles and responsibilities for the success of every project.

The roles of Scrum fall into two categories, i.e., core and non-core roes. In Scrum, core roles are defined as the roles that are mandatorily considered necessary for production of the project, they are and should be committed to the specific project and also responsible for success in every Sprint of the project and for the entire project. Non-core roles are those roles which are not mandatory in a Scrum project. The roles may consist of members interested in the project though they might not have any formal role in the team. But they are given permission to interact with the members of team. They may or may not be responsible for the outcome of the project. But in Scrum, it has been clearly specified that these roles should also be considered.

Here is a video on the Scrum Project Roles: http://www.scrumstudy.com/watch.asp?vid=454

Core Roles are further divided into three and they are held responsible for meeting the objectives of the project. Commonly referred to as the SCRUM core team, they are known by the names: Product Owner, Scrum Master and Scrum team. But the important fact to be taken into account is that these roles have or given no authority over other roles. Let us first consider the role of Product Owner. The responsibility of maximization of business value in a project is assigned to this role. It includes articulating requirements of the customer and maintenance of justification of business about the project. In short, Product Owner can be defined best as the Voice of the Customer.

Next is the Scrum Master role. Scrum Master can be best described as the person who ensures that the environment in which the team works is as per the guidelines that are required to develop the product or service successfully. Finally, the Scrum Team is a group of members responsible for understanding the requirements of the business as specified by the Product Owner, who estimates User Stories and creating the project Deliverables.

#scrum #agile #project management

scrum : Information Radiators or Tools in Scrum Projects

One of the main advantages of Scrum is that the whole activity is transparent for all and the information can be viewed directly from information tools such as Scrumboard, where the progress of the team can be made visible. The progress of a team can be planned accurately and tracked by the Scrumboard during each Interval of a Sprint. The Scrumboard consists of four columns for indicating the progress of the proposed tasks in a Sprint; the first one consists of the “To Do” column, i.e., for tasks in the pipeline, the second column consists of a “To Do” column for tasks that have not yet started, the third one for “In Progress” column for the tasks that are in action but not concluded and the final column stands for tasks which have been completed including the successful completing of tests. It has to be noted that in the initial stages of a Sprint, all the tasks for that phase are confined to the “To Do” column and their place changes as the project proceeds to completion.

The Scrum board is usually maintained on a white board or on paper, or as in recent times, where it is managed electronically on a Spreadsheet. Changes in the Scrumboard should be managed by the Scrum team as per the standards of time so that the information is transparent for the stakeholder and other team members to ensure that the project is on the right track as per the guidelines.

Another important tool in this regard is Impediment Log in which all the impediments affecting the project are documented. An Impediment is usually described as an obstacle, hindrance or hurdle which can decrease the productivity and performance of the Scrum team. It is mandatory that they should be identified as soon as possible, solution found in quick time and they should be removed in order for the team to contribute effectively. They can be classified into two types: Internal and External. Internal Impediments can be classified as either improper communication or reduction in performance of workforce whereas External impediments could involve various factors such as requirement of unnecessary documents or issues in software license. An organization can suffer from unwanted cost if it fails in identification or not finding an appropriate solution in dealing with this factor. The Scrum Master is responsible for recording the impediments in the Impediment Log and these issues can be discussed and sorted in Daily Standup Meetings and Sprint Review Meetings.

Sprint Burndown Chart is another key information radiator in Scrum. The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

Here is a video on the Sprint Burndown Chart: http://www.scrumstudy.com/watch.asp?vid=615.

#scrum #agile #project management

Scrum : Lifecycle of a Scrum Project

As with other certifications such as ITIL, PRINCE2 or PMP, SCRUM can also be described as an additional way in which organizations can achieve their goal of providing the best services or products to their customers. A new service which has to be designed or modification of an existing service can be termed as projects by organizations. But these so-called projects can become restrained due to shortage of time, resources, financial cost, and various challenges which can make an organization vulnerable to improper planning, execution, management and succession of projects. Organizations have henceforth formulated different methodologies for proper project management.

Scrum has become one of the most sought-after methodologies to be implemented for success of a project. One of the advantages of Scrum is that it ensures transparency for communication where the conversation becomes easy for collective accountability and consistent progress. Every methodology will have a special feature by which the challenges related to a project can be met. The benefits of Scrum are the usage of self-empowered, well-organized and across-department teams who can divide a project into little work cycles known popularly as Sprints.

Here is a video describing the Scrum methodology: http://www.scrumstudy.com/watch.asp?vid=434

Similar to the beginning of any project, the Scrum cycle also begins via a stakeholder meeting in which the details are explained to the delegate called as “Project Vision.” A Prioritized Product Backlog is then designed and developed by the Product Owner. The Backlog consists of a list of project and business requirements according to their priorities in the formula of user stories. A Sprint is usually begun with a “Sprint Planning Meeting” and during the discussion high priority issues and stories will be included in the sprint. The time-limit of a Sprint will be between one and six weeks and will involve the Scrum team.

The highlights of the meeting will be the short, to-the-point stand-up meetings which will be conducted and the SCRUM team will discuss the daily progress of the project. When the time-limit is concluded, a Sprint review meeting is conducted and the Product Owner and concerned stakeholders will be provided updates and demonstrations regarding the Deliverables. The Product Owner has the option to accept the Deliverables provided they meet the accepted criteria or reject it if they do not meet the concerned guidelines.

The conclusion of the Sprint Cycle is the “Retrospect Sprint Meeting” in which the team suggests ways on improving the processes and their performance in moving forward into the subsequent Sprint. Organizations that have used Scrum in their projects, vouch for its many benefits, some of them, adaptability, transparency, continuous improvement, motivation, faster problem resolution, and innovative environment.

#scrum #agile #project management

Scrum : Quality Considerations in Scrum Projects

“Quality is baked in,” we have often heard this statement. But to actually understand what it means in the Agile context, we need to have a QA mind-set. Let’s take an example to understand this. As part of a proposed acquisition, my boss asks me to perform some final due diligence on the development team and its product. We’d already established that the company’s recently launched product is doing well in the market, but I have to make sure we are not about to buy more trouble than benefit. So I spend my time with the development team.

Here is a video on quality considerations in Scrum project: http://www.scrumstudy.com/watch.asp?vid=585

I am looking for problems that might arise from having rushed the product into release. I wonder, “Was the code clean? Were there modules that could only be worked on by one developer? Were there hundreds or thousands of defects waiting to be discovered?” And when I ask about the team’s approach to testing, “Quality is baked in” is the answer I get. Because this rather unusual colloquialism could mean just about anything, I press further. What I find is that this is the company founder’s shorthand for expressing one of the quality principles: Bring quality in your development phase itself, rather than waiting for the testing phase. The idea of building quality into their products is at the heart of how agile teams work. Agile teams work in short iterations in part to ensure that the application remains at a known state of quality. Agile teams work in a cross-functional manner, with everyone working side-by-side in every iteration to improve the quality of the product thorough techniques like automation, refactoring, pair programming, integration etc.

Here a dedicated tester is involved throughout the timeline, continuously testing recently developed codes, and integrating them with the existing codes to conduct a functionality test as well. Smoke testing is also encouraged to improve the quality of the demo to be shown to the clients. Learning how to do these things is difficult, and especially so for testers, whose role changes dramatically in an Agile environment. It is important to look at the questions a tester will have in his/her mind while embarking on an agile project, such as:

· What are my roles and responsibilities?

· How do I work more closely with programmers?

· How much do we automate, and how do we start automating?

Once these questions are answered, a tester will be able to perform his/her role in an Agile environment in a much better way.

#scrum #agile #project management

Scrum : Managing Changes through Prioritized Product Backlog

Managing Changes through Prioritized Product Backlog Grooming A typical Prioritized Product Backlog will contain all User Stories, their time estimates which also includes 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.

Here is a video on managing change using Prioritized Product Backlog: http://www.scrumstudy.com/watch.asp?vid=590

A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Grooming Session) is a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth. It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.

#scrum #agile #project management

Scrum : Managing Changes through Prioritized Product Backlog

Here is a video on managing change using Prioritized Product Backlog: http://www.scrumstudy.com/watch.asp?vid=590

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. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints. A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Grooming Session) is a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth. It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.

Trending Blogs

Recently Viewed Blogs

SCRUMstudy