When is SCRUM Appropriate?
Scrum is intended for the kinds of work people have found unmanageable using defined processes — uncertain requirements combined with unpredictable technology implementation risks. When deciding whether to apply Scrum, as opposed to plan-driven approaches such as those described by the PMBOK® Guide, consider whether the underlying mechanisms are well-understood or whether the work depends on knowledge creation and collaboration. For example, Scrum was not originally intended for repeatable types of production and services.
The Scrum Team consists of three roles, namely a ScrumMaster, a Product Owner, and the Team.
The ScrumMaster (sometimes written as the Scrum Master, although the official term has no space after “Scrum”) is the keeper of the scrum process. He/she is responsible for:
• making the process run smoothly
• removing obstacles that impact productivity
• organizing and facilitating the critical meetings
2. Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
• Expressing Product Backlog items clearly.
• Ordering the Product Backlog items to best achieve goals and missions.
• Optimizing the value of the work the Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.
• Ensuring that the Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Team do it. However, the Product Owner remains accountable for these tasks.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Team to work from a different set of requirements, and the Team is not allowed to act on what anyone else says. This is ensured by ScrumMaster.
3. The Team
The Team is self-organizing and cross-functional. That means the team comprises of analysts, designers, developers, testers, etc. as appropriate and as relevant to the project.
Some people in the industry refer to this team as development team. However, such a reference is leading to controversy that the team can have only developers and no other roles. It is an obvious understanding that it is only a misconception. To develop a software product, we require all the roles and that is the essence of scrum – the team will function in collaboration. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team, and thus time and effort can be saved. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Optimal Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. The Team size should be kept in the range from five to nine people, if possible. Fewer than five team members decrease interaction and results in smaller productivity gains. Having more than nine members requires too much coordination.
The scrum team works together closely, on a daily basis, to ensure the smooth flow of information and the quick resolution of issues. The scrum team delivers product iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of a complete product ensure a potentially useful version of working product is always available.
ScrumMaster is a trained responsible person, who renders services as described below:
1. ScrumMaster Services to the Product Owner
The ScrumMaster serves the Product Owner in several ways, including:
• Finding techniques for effective Product Backlog management.
• Helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Understanding product planning in an empirical environment.
• Ensuring that the Product Owner knows how to arrange the Product Backlog to maximize value.
• Understanding and practicing agility.
• Facilitating Scrum events as needed.
2. ScrumMaster Services to the Scrum Team
The ScrumMaster serves the Scrum Team in several ways, including:
• Coaching the Scrum Team in self-organization and cross-functionality.
• Helping the Scrum Team to create high-value products.
• Removing impediments to the Scrum Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Scrum Team in organizational environments in which Scrum is not yet fully adopted and understood.
3. ScrumMaster Services to the Organization
The ScrumMaster serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption.
• Planning Scrum implementations within the organization.
• Helping employees and stakeholders understand and enact Scrum and empirical product development.
• Causing change that increases the productivity of the Scrum Team.
• Working with other ScrumMasters to increase the effectiveness of the application of Scrum in the organization.
EVENTS (How SCRUM works?)
Scrum Process Framework can be viewed by means of a sequence of events and the corresponding artifacts. The Scrum events are time-boxed events. That means, in a project, every scrum event has a predefined maximum duration. These events enable transparency on the project progress to all who are involved in the project. The vital events of scrum are:
• The Sprint
• Sprint Planning
• Daily Scrum Meetings
• The Sprint Review
• The Sprint Retrospective
During a Sprint, a working product Increment is developed. It is usually of duration two weeks or one month, and this duration remains constant for all the sprints in the project. We cannot have varying durations for the different sprints in a project. A new Sprint starts immediately after the conclusion of the previous Sprint.
The Sprint Goal is an objective set for the Sprint. It provides guidance to the Team on why it is building the Increment. It is created during the Sprint Planning meeting. The scope of the sprint is clarified and re-negotiated between the Product Owner and the Team as more about the requirements is learned. Thus, each Sprint is associated with it, a definition of what is to be built, a design, and the flexible plan that will guide building it, the development work, and the resultant product increment.
A Sprint should be cancelled if the Sprint Goal becomes obsolete. This might occur if the organization changes direction or if market or technology conditions change. A sprint can be cancelled only by product owner, though others have an influence on the same.
Due to the short duration nature of Sprints, cancellation during a sprint rarely makes sense. As the sprint cancellations consume resources, for getting re-organized into another Sprint, they are very uncommon.
If a Sprint is cancelled, and part of the work produced during the sprint is potentially releasable, the Product Owner typically accepts it. All the incomplete Sprint Backlog Items are put back into the Product Backlog.
The work to be performed in the Sprint is planned in the Sprint Planning Meeting. Sprint Planning Meeting is of duration of maximum of four hours for two weeks sprints and eight hours for one month Sprints. It is the responsibility of the Scrum Master to ensure that the meeting takes place and that all the required attendees are present and understand the purpose of the scheduled meeting. The Scrum Master moderates the meeting to monitor the sustenance of discussion and closure on time.
Sprint Planning focuses on the following two questions:
• What needs to be and can be delivered in the Sprint Increment?
• How will the work needed for the execution of Sprint be achieved? The inputs to this meeting are:
• The Product Backlog
• The latest product Increment
• Projected capacity of the Team during the Sprint
• Past performance of the Team
The Scrum Team discusses the functionality that can be developed during the Sprint. Product Owner provides clarifications on the Product Backlog items. The team selects the items from the Product Backlog for the Sprint, as they are the best to assess what they can accomplish in the Sprint. The Team comprises of analysts, designers, developers, and testers. The work is carried out in a collaborative fashion, thus minimizing re-work.
The Scrum Team then comes up with Sprint Goal. The Sprint Goal is an objective that provides guidance to the Team on why it is building the Product Increment. The Team then decides how it will build the selected functionality into a working product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
Work during a sprint is estimated during sprint planning and may be of varying size and/or effort. By the end of the Sprint Planning meeting, the work is divided into tasks of duration of one day or less. This is to enable the ease of work allocation, and tracking the completion. If the Team realizes that it has too much or too little work, it can renegotiate the selected Product Backlog items with the Product Owner.
The Team may also invite others (not part of Scrum Team) to attend the Sprint Planning meeting to obtain technical or domain advice or help in estimation.
Daily Scrum Meetings
The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily to quickly understand the work since the last Daily Scrum Meeting and create a plan for the next 24 hours. This meeting is also referred to as Daily Stand up Meeting.
The Daily Scrum Meeting is held at the same time and same place every day to reduce complexity.
During the meeting, each Team member explains:
• What did he do yesterday that helped the Team meet the Sprint Goal?
• What will he do today to help the Team meet the Sprint Goal?
• Does he see any impediments that prevent him or the Team from meeting the Sprint Goal?
Daily Scrum is mistaken to be a status tracking event, though, in fact, it is a planning event.
The input to the meeting should be how the team is doing toward meeting the Sprint Goal, and the output should be a new or revised plan that optimizes the team’s efforts in meeting the Sprint Goal.
Though the Scrum Master coordinates the Daily Scrum Meeting and ensures that the objectives of the meeting are met, the Meeting is the responsibility of the Team.
If necessary, the Team may meet immediately after the Daily Scrum Meeting, for any detailed discussions, or to re-plan the rest of the Sprint’s work.
Following are the benefits of Daily Scrum Meetings:
• Improve communication within the Team.
• Identify impediments, if any, in order to facilitate an early removal of the same, so as to minimize impact on the Sprint.
• Highlight and promote quick decision-making.
• Improve the Team’s level of knowledge.
A Sprint Review is held at the end of every Sprint. During the Sprint Review, a presentation of the increment that is getting released is reviewed. In this meeting, the Scrum Team and the stakeholders collaborate to understand what was done in the Sprint. Based on that, and any changes to the Product Backlog during the Sprint, the attendees arrive at the next steps required that could optimize value. Thus, the objective of Sprint Review is to obtain feedback and progress unitedly.
The Sprint Review is normally held for two hours for two week sprints and for four hours for one month sprints.
The Scrum Master ensures that
• The meeting takes place.
• The participants understand the purpose.
• The meeting is focused on the required agenda and is completed within the required duration.
The Sprint Review includes the following aspects:
• Attendees include the Scrum Team and key stakeholders, as invited by the Product Owner
• The Product Owner explains what Product Backlog items have been completed during the sprint and what has not been completed.
• The Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
• The Team demonstrates the work that it has completed and answers questions, if any, about the Increment.
• The entire group then discusses on what to do next. Thus, the Sprint Review provides valuable input to Sprint Planning of the subsequent Sprint.
• The Scrum Team then reviews the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product increment.
• The outcome of the Sprint Review is an updated Product Backlog, which defines the probable Product Backlog items for the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is usually a one hour meeting for two-week duration sprints and a three hour meeting for one month duration Sprints.
The purpose of the Sprint Retrospective is to:
• Combine the learnings from the last Sprint, with regards to people, relationships, process, and tools.
• Identify the major items that went well and potential improvements.
• Creation of a plan for implementing improvements to increase product quality.
The Sprint Retrospective is an opportunity for the Scrum Team to introspect and improve within the Scrum process framework so as to make the next Sprint outcome more effective.
SCRUM – Benefits
Scrum supports continuous collaboration among the customer, team members, and relevant stakeholders. Its time-boxed approach and continuous feedback from the product owner ensures working product with essential features all the times. Additionally, Scrum provides different benefits to the different roles in the project.
Benefits to Customer
The Sprints are of shorter duration and prioritized user stories are taken up at every sprint planning. It ensures that at every sprint delivery, the features as required by the customer immediately are included. Further, if a customer raises any change request, it will be absorbed in the current sprint, or included in the very next sprint. Thus, the development team quickly responds to the customer’s requirements very fast.
Benefits to Organization
Organization can focus on the effort required for development of the prioritized user stories and thus reduce overhead and rework. Due to the specific benefits of scrum to customer, increased efficiency of the development team, customer satisfaction and hence customer retention and customer references will be possible. It increases the market potential of the organization.
Benefits to Product Managers
Product Manager plays the role of Product Owner in the project. The responsibility of the product owner is to ensure customer satisfaction. Since Scrum facilitates quick responses, work prioritization, absorbing changes, product manager can easily ensure that the work is aligned to customer needs, which in turn ensures customer satisfaction.
Benefits to Project Managers
Project Manager plays the role of Scrum Master in the project. The collaborative nature of Scrum facilitates easy and concrete planning and tracking. The use of Burndown Charts to understand the work left, and the Daily Scrum meetings give the Project Manager awareness about the state of the project at all times. This awareness is essential to monitoring the project, and for catching and addressing issues quickly.
Benefits to Development Team
Due to the time-boxed nature of sprints and working product increment delivery at the end of every sprint, the development team becomes enthusiastic to see that their work is used immediately. The built in team collaboration makes the team enjoy the work they do. As the user stories for every sprint are based on customer priorities, team also understands that their work is valued.
...(download the rest of the essay above)