What is Scrum of Scrums?

What is Scrum of Scrums and how does it work in the product development process? The first thing to know about Scrum of Scrums is that it acquires relevance only for large projects where multiple Scrum Teams are involved. In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams.Normally, one member from each Scrum Team will represent his or her team in the Scrum of Scrums Meeting. In most cases, this is the Scrum Master, but at times someone else may represent the team. A single person may be nominated by the team to represent them in every Scrum of Scrums Meeting, or the representative may change over time, based on who can best fulfill the role depending on current issues and circumstances. Each person involved in the meeting should have the technical understanding to be able to identify instances in which teams could cause each other impediments or delays. Other important participants of Scrum of Scrums meeting include Chief Scrum Master and Chief Product Owner. The main purpose of the Scrum of Scrums Meeting is to communicate progress between multiple teams. The Chief Scrum Master (or any Scrum Master who would facilitate the Scrum of Scrums Meeting), can announce an agenda prior to the meeting. This allows individual teams to consider the agenda items in preparation for the Scrum of Scrums Meeting. Any impediments being faced by a team, which may also affect other teams, should be indicated so they can be conveyed at the Scrum of Scrums Meeting. In addition, if a team becomes aware of a large scale issue, change or risk that may affect other teams that should be communicated at the Scrum of Scrums Meeting. Outputs from the process Retrospect Sprint may have issues that could impact multiple Scrum Teams and could be used as an input for effective Scrum of Scrums Meeting. These meetings are preferably short (but usually not Time-boxed to allow for more sharing of information between teams) where a representative from each Scrum team meets to share status of the respective teams. The Scrum of Scrums Meeting is held at pre-determined intervals or when required by Scrum Teams, and these meetings facilitate the face-to-face sharing of information among different Scrum Teams through the Scrum of Scrums, issues, dependencies, and risks impacting multiple Scrum Teams can be closely monitored, which helps the various teams working on a large project better coordinate and integrate their work. It is the responsibility of the Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) to ensure that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. Each Scrum Team representative will provide updates from his/her team in turn. These updates are usually provided in the form of answers to four specific questions.

1. What has my team been working on since the last meeting?
2. What will my team do until the next meeting?
3. What were other teams counting on our team to finish that remains undone?
4. What is our team planning on doing that might affect other teams?

The answers to these four questions provide information that allows each team to clearly understand the work status of all other teams. It is recommended that a dedicated conference room be made available for the Scrum of Scrums Meeting, where all the Scrum Team Representatives are comfortable. In Convene Scrum of Scrums process, Scrum Guidance Body Expertise could relate to documented best practices about how to conduct Scrum of Scrum Meetings, and incorporate suggestions from such meetings in project work of individual Scrum Teams. There may also be a team of subject matter experts who may help the Chief Scrum Master facilitate the Scrum of Scrum Meeting. Some of the important outputs of the Scrum of Scrums meetings are: Coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams. By using Scrum of Scrums Meeting, there is collaboration across the organization as opposed to people working in closed teams concerned primarily with their individual responsibilities. The Scrum of Scrums Meeting is a forum where Scrum Team members have the opportunity to transparently discuss issues, impacting their project. The need to deliver every Sprint on time forces the teams to actively confront such issues early instead of postponing seeking resolution. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improve coordination between different Scrum Teams and also reduces the need for redesign and rework. Risks related to dependencies and delivery time tables are mitigated as well.

To know more, please visit : www.scrumstudy.com

Types of Scrum Masters

The Scrum Master is the “servant leader” of the Scrum Team who moderates and facilitates team interactions as team coach and motivator. The Scrum Master is responsible for ensuring that the team has a productive work environment by guarding the team against external influences, removing any obstacles, and enforcing Scrum principles, aspects, and processes. Different Scrum projects have different requirements, hence the need for different levels of Scrum Masters. Here are three such roles:

Chief Scrum Master

Large projects require multiple Scrum Teams to work in parallel. Information gathered from one team may need to be appropriately communicated to other teams—the Chief Scrum Master is responsible for this activity. The role of a Chief Scrum Master is necessary to ensure proper collaboration among the Scrum Teams. Coordination across various Scrum Teams working on a project is typically done through the Scrum of Scrums (SoS) Meeting. There is no hierarchy between the Scrum Masters: they are all peers. The Chief Scrum Master just works on a multi-team level, whereas the Scrum Masters work on a single team level. Typically, any inter-team issues are addressed by the interested parties in a session immediately following the Scrum of Scrums Meeting. The Chief Scrum Master facilitates this session. The Chief Scrum Master can be chosen from the Scrum Masters of the large project or can be somebody else. For very large projects, it is recommended to have a Chief Scrum Master who is not also a Scrum Master because the effort required for the Chief Scrum Master role will prevent the Chief Scrum Master from also being able to dedicate enough time to the work with his/her Scrum Team. In either case, the Chief Scrum Master should have enough Scrum expertise to be able to foster collaboration and to help and coach others with the implementation of Scrum for a smooth delivery of the project’s products. Apart from clearing impediments and ensuring a conducive project environment for the Scrum Teams, the Chief Scrum Master also collaborates with the Chief Product Owner, other Scrum Masters, and Product Owners in activities such as developing the list of components and resources needed in common for all teams throughout the project. He/she facilitates everything that goes beyond the realm of a single Scrum Team. The Chief Scrum Master also interfaces with the Program Scrum Master to ensure alignment of the large project with the goals and objectives of the program.

Program Scrum Master

The Program Scrum Master is a facilitator who ensures that all project teams in the program are provided with an environment conducive to completing their projects successfully. The Program Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the program; provides guidance to Scrum Masters of individual projects; clears impediments for the different project teams; coordinates with the Scrum Guidance Body to define objectives related to quality, government regulations, security, and other key organizational parameters; and, ensures that Scrum processes are being effectively followed throughout the program. The Program Scrum Master interfaces with the Portfolio Scrum Master to ensure alignment of the program with the goals and objectives of the portfolio. He or she is also involved with appointing Scrum Masters for individual projects and ensuring that the vision, objectives, outcomes, and releases of individual projects in the program align with that of the program. This role is similar to that of the Scrum Master except it meets the needs of the program or business unit rather than of a single Scrum Team.

Portfolio Scrum Master

This role is similar to that of the Scrum Master except it meets the needs of the portfolio or business unit rather than of a single Scrum Team.

 To know more, please visit : www.scrumstudy.com

How is Quality related to Scope and Business Value?

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.

The fact that Scrum, through repetitive testing, requires work to be Done in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. 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.

Quality and Scope

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

• The business need the project will fulfill
• The capability and willingness of the organization to meet the identified business need
• The current and future needs of the target audience

Scope of the project is the sum total 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.

The Prioritized Product Backlog is continuously groomed by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. During Sprint execution, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and Business Value

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 provide 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.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

To know more, please visit : www.scrumstudy.com

Sprint Backlog in Scrum

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

To know more, please visit : www.scrumstudy.com

Importance of SCRUM for HR

The Scrum Book of Knowledge defines Scrum as an adaptive, iterative, fast and flexible methodology designed to quickly deliver significant value during a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. Interestingly, applying Scrum successfully in a project also requires the human resource management practices of the organization where it is being implemented, to be in sync with Scrum.

In Scrum, there are two types of roles:

Core Roles: They are involved in creating the product of the project, are committed to the project, and ultimately are responsible for the success of the project.

Non-core Roles: They are non-compulsory team members, who have an interest in the project, may interface with the team, but may not be responsible for the overall success of the project. The non-core roles should also be taken into account in any Scrum project.

Typically, most organizations find it hard to discard Taylor’s scientific management theory. But to make Scrum teams work successfully, the HR has to give the cross-functional team a sense of responsibility and the control. After all, Scrum teams are expected to be self-motivated. They collaborate extensively to build products according to User Stories (users’ requirements), may a time negotiating with the Product Owner who is ultimately responsible for the Scrum team’s business decisions. Whilst executing a typical sprint, team members develop a sense of co-ownership as they set shared goals and learn how to manage each other in order to achieve them. But self-organizations of Scrum teams may be questioned when the team members are effected by performance appraisals, trying to impress managers, incentive schemes. This serves as a roadblock to Scrum’s core reasons of success: product-requirement alignment, feedback, self-motivation and morale. Along with the Scrum Master, it is also the HR’s job to help the Scrum team members to achieve their aims.

Another area where the HR’s role is important is during the appointment of the Scrum Master. The Scrum Master is the servant leader of the Scrum Team. He moderates and facilitates their interactions. He is responsible for solving their problems and ensuring the Scrum Team has a productive environment to work in. He guards the Scrum team from external influences and enforces Scrum processes. He also acts as the Scrum Team’s coach and motivator. Hence, it is important to find the right candidate for the job. One of the most common mistakes an HR makes when helping select the Scrum Master is that he ends up assuming that a manager is the default choice for the Scrum Master. Managers usually work in a boss-subordinate leadership style rather than being a servant leader. So when a manager is appointed as a Scrum Master for a team that includes his subordinates, they continue to regard the Scrum Master as a manager rather than managing the Scrum Team between themselves.

The Product Owner, on the other hand, requires a certain level of authority associated with his role. As Product Owners, the managers tend to get better results for each sprint out of their subordinates.

Effective Scrum requires longstanding, cross-functional teams. Progressive HR policies will allow Scrum teams to handpick their own members within these restrictions.

 To know more, please visit : www.scrumstudy.com

Essential Characteristics of 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”. – SBOK 2013 Edition.

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

All About Agile Testing

Coding and testing stages are not isolated ones but well integrated ones in Agile development. The development toward every user story commences through written business-interfacing experiments that enables the team the ‘what part’ regarding coding and also the juncture when the tasks are being completed with.

Professionals in the field of testing, analysis and development interface with stakeholders from the business side for extracting instances of preferred and unwanted manners for every single user story and aspect, and then transforming them into tests which are executable. This is known as Acceptance Test-Driven Development (ATDD) or Specification by Example. The team which is responsible for development will then work in partnership with their customers to choose the specific user story aligning customer expectations apropos the delivery part. User stories will be corroborated upon cracking the different functional, automated functional and manual probing tests.

Time is an important element which should be made inclusive for the whole activities related with testing toward user story estimates. This can include automated testing and manual probing testing. Inexperienced Scrum teams frequently and habitually over promise or goes overboard with their commitment part in terms of extra work planning compared to what they could feasibly do. Testing then gets hard-pressed in the end in the absence of features, due to this undesirable characteristic of the team simply because of the arrival of sprint on the last day. The result – mass demise of user stories hauled from one iteration to the subsequent one without the testing professionals being able to conduct their tests.

Focusing on completing each story at a specified time is a good way to handle this problem.

Necessary role inclusion for comprehending the various customer requirements and delivering good quality oriented software is a benefit that Agile teams possess inherently. Agile teams find the much needed opportunity through their varied experiences and assortment of abilities which help them in traversing different approaches toward supporting business participants in outlining their requirements. They are able to do it through tangible examples provided to the stakeholders and then interpreting the same into experiments certifying the ‘done part’ aimed at every user story along with their features.

Customers are pleased with the outcome pertaining to as an effort of the team – interacting and coordinating with the business teams, taking out the much needed time to plan for evidencing the aspects are done with as per requirements outlined. Newer Agile teams must pool in time to search for different means to comprehend the requisites of customers so that they can interpret those requisites into well conducted experiments which will outline software development. That will bring in maturity in terms of experience and doing things in a speedy manner efficiently and effectively.

To know more, please visit : www.scrumstudy.com

What is Planning Poker?

Planning poker is combination of analogy, expert opinion, and disaggregation in a fun way so that it will result quick and reliable estimates. All the team members are included in planning poker. On any agile project, you will have typically ten team members or less. If it does, the team can be split in twos. Then estimation is done independently by each team. The PO participates in planning poker but he or she doesn’t estimate.

At the beginning, each team member is handed deck of cards. All the cards are marked with a valid estimation number. Each member will be given a deck that reads a number series. The most popular of these estimation numbers are Fibonacci numbers. (1,2,3,5 ,8,13,2, 34,55 and so on). The cards are prepared before the planning poker meeting.

Then a moderator describes each of the user stories or theme that team is planning to estimate. Though generally the product owner acts as a Moderator, anyone can be a moderator. No special privilege or role is associated with the moderator. The product owner will answer all questions that the team members have.

The goal of estimation is to be somewhere on the left of the actual effort line. Important thing to remember is that this process is not about deriving an estimate that will resist all future inspection.

After all the queries are resolved, each team member selects a card that represents their estimation. Each estimator has to make a selection before Cards can be visible to everyone. Cards are kept private until everyone has estimated. Then the cards are turned over at the same time.
Then, all cards are instantaneously spun over and displayed so that all estimators can see each estimate. Chances are that these estimates will differ significantly. In that case, the high and low estimators will explain their estimates. The focus of this process is not to attack these estimators but to learn on what basis these estimations were assigned.

After this discussion, each team member will re-estimate by selecting a card. The earlier mentioned process will be followed again. Chances are that the estimates will meet by the subsequent round. Continue to repeat the process until all the estimators converge on a single estimate that can be used for the story. Very rarely it takes more than three rounds. Continue this process until estimates are moving closer together and they everyone converges on a single estimate.

To know more please visit: www.scrumstudy.com

All about Time-boxing in SCRUM

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.

To know more, please visit : www.scrumstudy.com

All about Agile Methodologies

The term “agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, agile as a quality should therefore be a good thing to aim for. Agile project management specifically, involves being adaptive during the creation of a product, service, or other result.

A number of Agile methodologies originated and gained traction in the 1990’s and the early 2000’s. Here are the various popular Agile methodologies being used.

Lean Kanban: Lean concept optimizes an organization’s system to produce valuable results based on its resources, needs, and alternatives while reducing waste. Kanban literally means a “signboard” or “billboard” and it espouses the use of visual aids to assist and track production.

Extreme Programming (XP): Originated in Chrysler Corporation, gained traction in the 1990′s. XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.

Crystal Methods: Introduced by Alistair Cockburn in the early 1990s, Crystal methods have four roles—executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility.

Dynamic Systems Development Methods (DSMD): This framework was initially published in 1995 and is administered by the DSDM Consortium. DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into “Must have,” “Should have,” “Could have,” and “Won’t have” categories

Feature Driven Development (FDD): Introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks’ time. FDD has two core principles—software development is a human activity and software development is a client-valued functionality.

Test Driven Development (TDD): Also known as Test-First Development, and was introduced by Kent Beck, one of the creators of Extreme Programming (XP). It is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.

Adaptive Software Development (ASD): This method grew out of the rapid application development work by Jim Highsmith and Sam Bayer. The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.

Agile Unified Process (AUP): Evolved from IBM’s Rational Unified Process and developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.

Domain-Driven Design (DDD): This approach was meant for handling complex designs with implementation linked to an evolving model. It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain.

All these methods of Agile differ from each other in a variety of aspects but their commonality stems from their adherence to The Agile Manifesto.

To know more, please visit : www.scrumstudy.com