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