Tag Archives: #project management

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
For more informative articles on Scrum and Agile, please visit www.scrumstudy.com
Follow us on twitter – @SCRUMstudy_

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

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

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

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

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.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Implementing Scrum in Organizations

Scrum is not your regular waterfall technique but an agile framework which changes and, at times, challenges traditional roles. The Organizational Resource Matrix is a hierarchical depiction of a combination of a functional organizational structure and a projectized organizational structure. Matrix organizations bring together team members for a project from different functional departments such as information technology, finance, marketing, sales, manufacturing, and other departments – and create cross-functional teams. Managers, developers, and testers will be assigned the roles of the Product Owner, the Scrum Master, and the Development Team (Scrum Team).

The Skills Requirement Matrix, also known as a competency framework, is used to assess skill gaps and training requirements for team members. A skills matrix maps the skills, capabilities, and interest level of team members in using those skills and capabilities on a project. Using this matrix, the organization can assess any skill gaps in team members and identify the employees who will need further training in a particular area or competency. Team members may not always possess the required knowledge or skills to work in the Scrum environment. The Product Owner should evaluate the training needs of potential team members and facilitate training to bridge any knowledge gaps in the team.

The Product Owner is normally responsible for evaluating and selecting team members, but often does this in consultation with the Scrum Master who may have additional knowledge of the resources from working with them on other projects. Appropriate training should be provided to the Scrum Team members both prior to the commencement of work, and also when they are working on their projects. Scrum Team members should also be ready to learn from each other and from more experienced persons in the team. The awareness level of Scrum in an organization needs to be assessed which will help probe into the readiness of an organization and its people for Scrum.

There are different aspects of an organization that needs to be gauged: organizational, infrastructural, business, team, technological, and procedural. The results of the assessment will allow for a more specific awareness generation or training in the area concerned.  Product Managers, Project Managers, Functional / Departmental Managers, Scrum Team Members (including Architects, Designers, Coders, Testers, and others), and Executives in organizations doing Scrum must be provided with the right level of insight into Scrum for its successful implementation. Insight should not just be provided to the core roles (Product Owner, Scrum Master, and Scrum Team) but should also extend to the non-core roles (Users, Stakeholders, Consulting Experts, and Management).

Creating a good cooperation and continuous exchange of information between these two roles is crucial to the success of a project. The non-core roles have to be actively involved in envisioning the product and providing feedback as to “what” should constitute the desired product. The Scrum Team and the Product Owner should be left to figure out the “how” of achieving the desired results.  Changed to Scrum team. Therefore, the Scrum Team must be trained to actively seek feedback from the Product Owner who funnels the feedback from the other non-core roles, and those stakeholders must be sensitized well in the practices of Scrum so that they do not interfere with the workings of the Scrum Team.

For a well-developed Scrum implementation in an organization, the level of awareness about Agile principles and values must be extensive. The Scrum Team has to be sensitized and trained in the ways of Scrum and the Scrum Master should act like a coach. The Scrum Master needs to bring out the best from the Scrum team by motivating them and facilitating the development process. Apart from the Scrum Team, the Product Owner also needs to be trained well.  The Product Owner is the bridge between requirements and development. The more he/she is able to understand the requirements the better product development will be.

Implementation of Scrum changes not just the development team or a few management executives associated with a team or a project but at every level of the organization. Change at an organizational level is complex and is influenced by various factors: the culture of an organization, insecurity of managers, employee resistance, failure to see the need for change, fear of the unknown. These hurdles need to be addressed professionally by the Scrum Master. Clear objectives need to be communicated to all personnel about the implementation of Scrum.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

6 Main Principles of Scrum Methodology

Scrum principles are the foundation on which the Scrum framework is based. The principles of Scrum can be applied to any type of project or organization, and they must be adhered to in order to ensure appropriate application of Scrum.

The aspects and processes of Scrum can be modified to meet the requirements of the project, or the organization using it, but Scrum principles are non-negotiable and must be applied as described in the framework presented in A Guide to the Scrum Body of Knowledge the SBOK™ Guide. Keeping the principles intact and using them appropriately instills confidence in the Scrum framework with regard to attaining the objectives of the project.

  • Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
  • Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth.
  • Collaboration—This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
  • Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from early in the project and continuing throughout.
  • Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.
  • Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

Scrum principles are the core guidelines for applying the Scrum framework and should mandatorily be used in all Scrum projects. The Scrum aspects and processes, however, can be modified to meet the requirements of the project or the organization.

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

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.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog