Scrum and Kanban, alike or different?

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

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

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

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

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

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

To Know More,Please Visit - www.scrumstudy.com

7 C’s of Scrum

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

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

To Know More,Please Visit - www.scrumstudy.com

What justifies your Project?

A routine question before starting a project is “Why is this needed?” Such a question might be posed by primary school students who are assigned to create a diorama about the water cycle. But the question is just as likely to be raised when dealing with large projects in the corporate world. The answer to “Why is this needed” lies in the business justification, which includes the reasons for undertaking a project, according to A Guide to the Scrum Body of Knowledge (SBOK^™).

Business justification drives decision making, so it is important to assess the potential of a project before committing to significant investment at early stages and to verify the business justification throughout the lifecycle. A project should be terminated if it is deemed unviable. The decision should be escalated to relevant stakeholders and senior management. The business justification for a project must be assessed at the beginning of the project, at pre-defined intervals and at any time when major issues or risks emerge that threaten viability.

There are numerous factors a Product Owner must consider to establish the business justification for a project. Here are some of the more important ones:

• Project Reasoning: Includes all factors that necessitate the project, whether positive or negative, chosen or not. Examples include inadequate capacity to meet existing and forecasted demand, decrease in customer satisfaction, low profit and legal requirement.
• Business Needs: Those business outcomes that the project is expected to fulfill, as documented in the Project Vision Statement.
• Project Benefits: Include all measurable improvements in a product, service or result that could be provided through successful completion of the project.
• Opportunity Cost: Determine the value of the next best business option or project that was discarded in favor of the current project.
• Major Risks: Include any uncertain or unplanned events that may affect the viability and potential success of the project.
• Project Timescales: Reflect the length or duration of a project and the time over which its benefits will be realized.
• Project Costs: Investment and other development costs for a project. Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle.

Let’s take a look at how business justification is determined:

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

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

Confirm Benefits Realization: The Product Owner confirms the achievement of organizational benefits throughout the project as well as upon completion of the User Stories in the Prioritized Product Backlog. Benefits from Scrum projects are realized during Demonstrate and Validate Sprint, Retrospect Sprint, Ship Deliverables and Retrospect Project processes. When you’re in school, you can scrap a project at any point and the only thing that’s on the line is an assignment grade. But unacceptable project results in the professional world are far-reaching. To give yourself the best opportunity for success, you should always ask “Why is this needed?” and lean on the business justification to find your answer.

To Know More,Please Visit - www.scrumstudy.com

What are the Cultural Challenges in adopting SCRUM Methodology?

Scrum methodology is being used as a successful Project Management or Product Management process in many organizations. It’s been gaining in popularity over the last 15 years, as more and more organizations realize the benefits of Scrum. But before a particular team/organization embraces Scrum or any other Agile process, the biggest hindrance comes from the management, which is generally resistant to change, even in the face of evidence.

Let’s look at some of the cultural challenges and how to overcome them:

1. Independent Decision Making: Scrum encourages independent thinking and decision making, while in most corporate structure, a top-down process of decision making takes places. Also, larger the organization more will be the hierarchies, and independent decision making becomes that much more difficult. To overcome this problem, senior management buy-in is a must, and they have to be convinced of the benefits of religiously following Scrum as a practice.
2. Customer Relationship: Generally, a traditional vendor-supplier relationship between the organization and the client will not augur well for practicing Scrum. Customers have to get much more involved with the development team, and periodic feedback becomes the norm rather than exception. Here again, the client can appreciate the effort being put in by the development team, if they are closely involved in the planning the backlog and sprint items.
3. Quality Philosophy: In a traditional structure, quality teams focus a lot on metrics and charts and graphs etc., while Scrum lays emphasis on Collaborative Approach. What it means is that e.g. Testing is not done only by a Tester, but also by a Business Analyst or Technical Manager. Every member of the Scrum team takes the responsibility of bringing in Quality in the development process, and every member contributes to Quality and Process Improvement. Basically, this change of approach means delegating authority, which may face stiff resistance from QA and Testing managers
4. Sustainable Pace of Development: In the traditional process, testing and bug fixing happens during the last few weeks of the project phase, wherein everyone from the developers to the technical architects to the testers work overtime and during weekends to complete the task. Agile on the other hand is all about sustainable pace of development, wherein every sprint, the code will be developed and tested. Although this process reduces uncertainty and hastiness, the fact that testers are not used to work in this kind of environment, and their acceptance will take time. To counter this issue, during the first few Scrum Projects, when everyone is new to Agile, testing should be handled by a team of tester rather than a single tester. They will collaborative and work on issues, which will make them comfortable in this process. Later on, they can independently handle different projects.

So, these were just some of the cultural challenges that teams face while adopting a SCRUM approach.

To Know More,Please Visit - www.scrumstudy.com

Is ‘Change’ accepted in Scrum?

Every project, regardless of its method or framework is exposed to change. It is imperative that project team members understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that arise from change and minimize any negative impacts through diligent change management processes in accordance with the principles of Scrum.

In today’s hypercompetitive world where technology, market conditions, and business patterns are continuously shifting, change is the only constant. A primary principle of Scrum is its acknowledgement that a) stakeholders (e.g., customers, users, and sponsors) do change their minds about what they want and need throughout a project (sometimes referred to as “requirements churn”) and b) that it is very difficult, if not impossible, for stakeholders to define all requirements during project initiation.

Scrum development projects welcome change by using small development cycles that incorporate customer feedback on the project’s deliverables after each Sprint. This enables the customer to regularly interact with the Scrum Team members, view product increments as they are ready, and change requirements earlier on in the development cycle. Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.

To Know More,Please Visit - www.scrumstudy.com

Ensuring your team does not have too much or too little to do!

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating). Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

Scrum Time-Boxes

Sprint—A Sprint is a Time-boxed iteration of one to six weeks in duration, during which the Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external impediments during the Create Deliverables process. This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team works to convert the requirements in the Prioritized Product Backlog into shippable product functionalities. 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.

Daily Standup Meeting—The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. The team members get together to report the progress of the project by answering the following three questions:

1. What did I complete yesterday?
2. What will I complete today?
3. Am I facing any impediments?

This meeting is carried out by the team as part of the Conduct Daily Standup process.

Sprint Planning Meeting—This meeting is conducted at the beginning of a Sprint as part of Create Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint. The Sprint Planning Meeting is divided into two parts:

1.               I.      Objective Definition—During the first half of the meeting, the Product Owner explains the highest priority User Stories or requirements in the Prioritized Product Backlog to the Scrum Team. The Scrum Team in collaboration with the Product Owner then defines the Sprint goal.
2.            II.      Task Estimation—During the second half of the meeting, the Scrum Team decides “how” to complete the selected Prioritized Product Backlog Items to fulfill the Sprint goal.

Sprint Review Meeting—The Sprint Review Meeting is Time-boxed to four hours for a one-month Sprint. During the Sprint Review Meeting that is conducted in the Demonstrate and Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the

Product Owner – The Product Owner reviews the product (or product increment) against the agreed Acceptance Criteria and either accepts or rejects the completed User Stories.

Retrospect Sprint Meeting—The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-
month Sprint and conducted as part of the Retrospect Sprint process. During this meeting, the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow. Some improvement opportunities or best practices from this meeting could also be updated as part of the Scrum Guidance Body documents.

To know More,Please Visit - www.scrumstudy.com

Roles and Responsibilities of a Scrum Master July 19, 2017

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

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

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

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

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

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

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

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

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

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

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

The delivery manager is now accountable for training agile.

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

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

To Know More,Please Visit - www.scrumstudy.com

Who are Stakeholders?

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

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

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

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

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

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

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

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

To Know More,Please Visit - www.scrumstudy.com

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

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

To overcome these constraints, value-driven delivery must be the main focus. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle. One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

In order to provide value-driven delivery, it is important to:

• Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog
• Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with project stakeholders and show them product increments as each is created and allow them to manage changes effectively.
• Create deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

The concept of value-driven delivery in Scrum is quite different when compared with the principles of traditional project management models where:

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

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

To Know More,Please Visit - www.scrumstudy.com

How to form a Scrum Team?

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

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

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

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

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

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

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

Team Building Plan

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

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

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

To Know More,Please Visit - www.scrumstudy.com

Business Justification in SCRUM

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

1. Assess and Present a Business Case

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

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

3. Confirm Benefits Realization

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

The following figure summarizes the steps to determine business justification.

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

To Know More,Please Visit- www.scrumstudy.com

What is Self-Organizing?

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

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

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

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

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

To Know More,Please Visit- www.scrumstudy.com

Tools to Create Project Vision

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

The Project Vision Meeting

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

JAD Sessions

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

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

SWOT Analysis

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

Gap Analysis

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

 

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

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

To Know more,Please Visit - www.scrumstudy.com

Delivering Value in Scrum

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

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

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

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

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

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

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

To Know More,Please Visit - www.scrumstudy.com

All about Retrospect Sprint Meeting

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

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

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

Other tools used in the Process of Retrospect Sprint are:

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

The outputs of the Retrospect Sprint are:

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

To Know More,Please Visit- www.scrumstudy.com

Characteristics of a Great Scrum Team

In a Scrum project, it is the Scrum Team members who are responsible for delivering the desired product or service and not the Scrum. Hence, we should be careful in forming the Scrum Teams.

The Scrum Team is sometimes referred to as Development Team since they are responsible for developing the product, service or other results. It consists of a group of individuals who the user stories in the Sprint Backlog to create deliverables for the project.

The essential characteristics of a Scrum Team for delivering the desired project results are described below:

Self-Organized: The scrum team members are motivated individuals who do not wait for their superiors to assign the tasks. They take the responsibility, share the risk, take decision, and work collectively towards a common goal.

Empowered: The Scrum Team or the development team is supplied with the required resources to deliver the desired products or services along with the authority to take the decisions. If the team has only the responsibility but no authority to take decisions, the continuous/iterative development is difficult.

Collaboration: Project management is a shared value creation process with teams working and interacting together to deliver greatest value. The scrum team should share the knowledge, ideas, risk and responsibilities, and work in harmony with the team members to deliver desired results.

Shared Goal: The individuals within the team should work collectively towards a common goal. The team goal should superimpose their individual goals like growth, appraisal, and money.  

  

Optimum Size: A small Scrum team may not have the required skill to develop the product or service and a large Scrum team may spoil the work as the collaboration within the team will be difficult. As defined in the SBOK, the optimum size of the Scrum team should be six to ten. This will ensure that, the Scrum team is large enough to possess necessary skills to deliver the project and small enough to collaborate.

Diverse Skills: The Scrum Team should collectively possess the necessary skills to deliver the project deliverables. During scrum team formation the team members should be selected keeping in mind the skills required to deliver the project deliverables.

Collocated: It is advised to form a Scrum team with the members collocated. This ensures collaboration and coordination within the team members

To Know More,Please Visit- www.scrumstudy.com

Agile User Stories

User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. A User Story tells you three things about the requirement: Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. The predefined, standard format results in enhanced communication among the stakeholders and better estimations by the team.

The Product owners create User Stories which are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. The Product Owner, based on his or her interaction with the stakeholders, business knowledge and expertise, and inputs from the team, develops User Stories that will form the initial Prioritized Product Backlog for the project. At times, the Product Owner may bring a Business Analyst to assist with writing User Stories.

How User Stories are created?

User Story Workshops  User Story Workshops are useful in understanding user expectations for the deliverables and are excellent for team building. They also facilitate preparation for the planning of the next Sprint. A User Story Workshop is a good platform to discuss and clarify every element of a product and often delve into the smallest details to ensure clarity. These workshops help the Product Owner to prioritize requirements and enable the Scrum Core Team to have a shared perspective of the Acceptance Criteria. They ensure that the Epics and User Stories describe the functionality from the users’ point of view, are easy to understand, and can be reliably estimated.

User Group Meetings

User Group Meetings involve relevant stakeholders (primarily users or customers of the product). They provide the Scrum Core Team with firsthand information about user expectations. This helps in formulating the Acceptance Criteria for the product and provides valuable insights for developing Epics. User Group Meetings are vital in the prevention of expensive rework that may result from a lack of clarity regarding expectations and requirements. These meetings also promote buy-in for the project and create a common understanding among the Scrum Core Team and relevant Stakeholder(s).

Focus Group Meetings

Focus Group Meetings are a qualitative technique to gauge and understand user needs and expectations about a proposed product. A small group of users are selected to form the focus group. This group may be selected randomly from a large pool of users or can be selected specifically to represent all the major Personas being targeted. Focus Group Meetings normally adhere to a certain format in which the group is asked questions that they then discuss among themselves. Each Focus Group Meeting can have its own rules of discussion as decided by the organizers. These meetings are usually held in the presence of a moderator.

User or Customer Interviews

Engaging stakeholders, including the sponsor, users, and customers of the product, is important to gain the necessary context and insight required to develop Epics. Quality time spent interviewing users and customers will result in ensuring that the requirements in Epics align with the overall Project Vision, thereby delivering greater value.

Questionnaires

A cost effective way to gain quantitative and qualitative statistical insight from a large number of users or customers is to use surveys or Questionnaires. A Questionnaire is a research instrument that contains questions to be asked to a respondent in order to collect information about a specific issue or topic. Questionnaires can be self-administered or administered by an interviewer. In conclusion, user stories are the best way to document the requirements from the end uses perspective. The Use Stories can be written in several ways but the basic aim of creating these User Stories is to understand the requirements of the end user and implementing them accordingly.

To read more interesting articles about scrum and agile, visit – www.SCRUMstudy.com/blog

Also for all latest updates and information on SCRUM follow @SCRUMStudy_ on Twitter

To Know More,Please Visit www.scrumstudy.com

Need for SBOK™

Ken Schwaber and Jeff Sutherland played a key role in elaborating 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. After that time, several Scrum practitioners, experts and authors have continued to improve 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.

In recent years, it has become evident that organizations which use Scrum as their preferred project delivery framework consistently deliver very high Returns on Investment. The focus of Scrum on value-driven delivery helps Scrum Teams deliver results as early in the project as possible.

The SBOK^™ was developed as a means to create a necessary guide for organizations and project management practitioners who want to implement Scrum, as well as those already doing so who want to make needed improvements to their processes. It is based on experience drawn from thousands of projects across a variety of organizations and industries. The contributions of many Scrum experts and project management practitioners have been considered in its development.

The SBOK^™ is especially valuable:

• to Scrum Core Team members including:

°      Product Owners who want to fully understand the Scrum framework and particularly the customer/stakeholder-related concerns involving business justification, quality, change, and risk aspects associated with Scrum projects

°      Scrum Masters who want to learn their specific role in overseeing the application of Scrum framework to Scrum projects

°      Scrum Team members who want to better understand Scrum processes and the associated tools that may be used to create the project’s product or service

• as a comprehensive guide for all Scrum practitioners working on Scrum projects in any organization or industry
• as a reference source for anyone interacting with the Scrum Core Team, including but not limited to the Portfolio Product Owner, Portfolio Scrum Master, Program Product Owner, Program Scrum Master, Scrum Guidance Body, and Stakeholders (i.e., sponsor, customer, and users)
• as a knowledge source for any persons who have no prior experience or knowledge of Scrum framework but wants to learn detail about the subject

The content of the SBOK^™ is also helpful for individuals preparing to write the following Scrumstudy^™ certification exams:

• Scrum Developer Certified (SDC^™)
• Scrum Master Certified (SMC^™)
• Agile Expert Certified (AEC^™)
• Scrum Product Owner Certified (SPOC^™)
• Expert Scrum Master (ESM^™)

To Know More,Please Visit www.scrumstudy.com

Overcoming the Challenges faced by a Scrum Team

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

Some of the challenges faced by a Scrum Team are:

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

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

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

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

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

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

To Know More,Please Visit www.scrumstudy.com

What is a Persona?

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

Creating a Persona

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

An example for this concept Personas

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

To Know More,Please Visit www.scrumstudy.com

Risk Management in Scrum

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

Risk Management consists of five steps:

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

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

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

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

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

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

To Know More,Please Visit www.scrumstudy.com

Scalability of Scrum

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

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

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

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

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

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

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

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

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

Achieving Scalability:

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

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

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

To Know More,Please Visit www.scrumstudy.com