Overview

Definition

The definition of Scrum in Scrum Guide (2017):

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

According to this, the key information can be extracted:

• Scrum is a framework that people can employ various techniques, methods and tools that facilitate the working process but are not in conflict with the rules of Scrum;
• Scrum is appropriate for being used to address the complex and adaptive problems. ‘Complex’ means the relationship inside the problem can only be understood in retrospect and is addressed by ’emergent practise’ which may evolve to a new way of working (Cynefin framework). And ‘adaptive’ refers to the situation of the problem would change dynamically over time;
• Scrum aims to maximise the value of the products. This scenario satisfies the customer’s real needs by focusing on value instead of the output. The entire Scrum team should be aware that the very first principle of the Agile Manifesto refers to delivering value; and
• Scrum relies on productive and creative workflow. High-productivity accelerates iteration and feedback loops resulting in assessing value quickly. And creative work, such as experiments and spikes, provides more opportunities to learn and reduce risks from a technical or customer viewpoint.

Essentials

Scrum is instituted based on empirical process control theory, a.k.a. empiricism. It means that ‘knowledge comes from experience and making decisions based on what is known‘ (The Scrum Guide), which means improvements toward the right destination could emerge from what has already happened accordingly. Based on this, products, team and working environment will be improved throughout the iterative and incremental process of Scrum. All implementations within the Scrum framework are advocated by empiricism that is founded on the basis of ‘three pillars’ (3 principles). And there are three vital components (roles, artifacts and events) surrounded by five values of Scrum within which people can implement the framework successfully. The Scrum Guide illustrates that ‘The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them‘, while in my view, complying the Scrum rules prevents the efficacy of all essentials of Scrum from internal and external disruptions. All essentials identified in the Scrum Guide are listed as follows.

• 3 Principles
  • Transparency
  • Inspection
  • Adaptation
• 5 Values
  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect
• 3 Roles
  • Development Team
  • Product Owner
  • Scrum Master
• 3 Artifacts
  • Product Backlog
  • Sprint Backlog
  • Increment
• 5 Events
  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Practice

Basis

Scrum framework is used to manage the development process of a complex adaptive project. The entire project process is constituted by a series of Sprints. A sprint commences immediately when the prior sprint is done. Each sprint aims to produce a potentially releasable increment of ‘Done’ product based on its Sprint Goal as one of the inputs to the upcoming Sprint. Also, the improvements are identified at the end of each Sprint and implemented during the next Sprint. In addition, Sprint Zero, the first phase shown in the above figure, is a specific sprint at the beginning of a piece of work in order to address many upfront activities, while it is not defined in the Scrum Guide.

Sprint Zero (Optional)

As mentioned above, Sprint Zero can be employed as the first phase to address the upfront activities. This is because such activities must be done and some artifacts such as the Product Backlog and the Definition of ‘Done’ should be built before the first Sprint commences. Consequently, Sprint Zero is one of the optional solutions to accomplish the initialisation systematically. It should be noticed that there is no formal standard for Sprint Zero and it is considered both positively and negatively by the agile community. The activities can be conducted during the Sprint Zero include:

• Visioning
  • A process of coming up with breakthrough ideas;
  • Producing the project’s vision which is crucial for the whole team to understand, collaborate and commit towards the same goal throughout the entire project.
• Forming a team
  • Building a cross-functional team in place;
  • Allocate responsibilities to each member.
• Initialising Sprint environment
  • Developing a Scrum board;
  • Setting-up the duration of each event, the site and time of Daily Scrum;
  • etc.
• Drafting the Product Backlog
  • Adding initial epics or user stories;
  • Estimating and prioritising them;
  • Conducting detailed requirements communication probably;
  • etc.
• Defining the Definition of ‘Done’
  • A baseline for assessing the completed work.
  • Providing suggestions to the Development Team on how many Product Backlog items can be selected.
• etc.

Sprint

Sprint is the heart of Scrum. As a container, Sprint limits the duration of implementing all the events inside it from 2 to 4 weeks basically. These events are executed by specific roles identified in the Scrum Guide independently and sequentially. Sprint Planning is the first event used to develop a plan and a Sprint Goal guiding the work during the Sprint. Daily Scrum, as well as stand-up meeting, is held for reviewing and planning the work each day. The output of the current Sprint would be discussed in the Sprint Review. And the Sprint Retrospective aiming to evaluate the work starts after the Sprint Review and prior to the next Sprint. In addition, cancelling a Sprint occurs if the Sprint Goal is no longer valid.

Sprint Planning

During the Sprint Planning, the Scrum Team need to address three questions: what to do, how to do this Sprint and what is the Sprint Goal.

For the first question, the Development team and Product Owner mutually addresses it. The highest ordered Product Backlog items with more detail are considered by the Development Team based on the various aspects including the conditions of the last ‘Done’ increment, the projected capacity of the Development Team, Definition of ‘Done’, etc. While the Product Owner will discuss and negotiate with them in order to commit the team to deliver the highest possible value. But only the Development Team can assess what it can accomplish over the upcoming Sprint.

With regard to how to achieve the work, the Development Team takes accountability for it solely via estimating, converting and decomposing selected items to tasks in the Sprint Backlog. During this step, the Product Owner can help to clarify the selected Product Backlog items, re-negotiate and make trade-offs.

A list of tasks representing the HOW of the increment created
=
the Product Backlog items selected for the Sprint
+
the plan for delivering them

In addition, the Sprint Backlog must contain at least one improvement task identified in previous Sprint Retrospectives.

Sprint Backlog 
= 
A list of tasks representing the HOW of the increment created
+
at least one improvement task from previous Sprint Retrospectives

The most important output of the Sprint Planning is the Sprint Goal which is ‘an objective set for the Sprint that can be met through the implementation of Product Backlog‘. Sprint Goal has the following characteristics:

• A baseline for detecting undesirable variances;
• Cannot be changed before the Sprint done or cancelled;
• Gives the Development Team some flexibility regarding the functionality implemented within the Sprint;
• Provides guidance to the Development Team on why it is building the Increment.

Development Work

The Development Team, as a self-organising team, performs the development work iteratively and incrementally throughout the Sprint based on the Sprint Backlog. During this period, the Product Owner continuously collaborates with the Development team to satisfy the Sprint Goal. The deliverables of the development work are the potentially releasable functionalities or increments which must be in useable condition and meet the definition of ‘Done’.

Refinement

Refinement is an activity implemented with the development work simultaneously. Unlike the development work, the target artifact of Refinement is the Product Backlog. Only the Product Owner takes accountability for modifying the items in the Product Backlog based on the latest requirements from the customer, the current situation of the project and also the estimates and advice provided by the Development Team. A revised Product Backlog with more detailed and re-ordered items will be delivered to best achieve goals and missions.

Daily Scrum

Daily Scrum, a.k.a. Stand-up Meeting, is:

• a key inspect and adapt meeting toward the Sprint Goal;
• in 15 minutes stringently;
• placed at the same time and site each day stringently;
• a meeting during which only the attendees from the Development Team can present;
• used to synchronise activities acting as reporting progress and updating relevant information on the Scrum Board;
• used to create a plan for the next 24 hours;
• used to identify and implement improvements informally.

A widely-used meeting structure is kind of question-based which guides each attendee answer three questions around the work has done, the plan and the identified blockers. And it is also a typical example introduced in the Scrum Guide. But I personally prefer the task-based structure of Daily Scrum, within which the development team member responsible for each task on the Sprint Backlog presents the progress, plan and blockers accordingly and sequentially. Compared with the sample structure introduced in the Scrum Guide, each member could take more concentration on the information in other members turn.

Obviously, there is no enough time for attendees to have further discussions in order to commence the next work and address problems. Hence, the team members should meet immediately after the meeting for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

Sprint Review

Sprint Review aims to review the output of this Sprint resulting from the work of the Development Team to elicit feedback. Concerning this output, it has a specific name in Scrum: potentially releasable Increment, which means the output should be always available regardless of whether the Product Owner decides to release it. The Product Owner representing the customer’s interests is fully responsible for the product. Therefore, the major attendants consist of the Development Team, the Product Owner and also some key stakeholder invited by the Product Owner. During the meeting, attendants collaborate and discuss the following topics:

• the development progress of the product;
• the problems appeared during the process of delivering the product;
• the Increment and the Product Backlog;
• the next development plan;
• the internal and external situations, including the marketplace, customer’s feedback, timeline, budget, etc.
• etc.

The Sprint Review results in a revised product backlog identifying the possible product backlog items for the following sprint. Overall the Product Backlog may also be modified to satisfy new opportunities.

Sprint Retrospective

Sprint Retrospective is the final event of a Sprint. This is a structured opportunity for all team members, including the Scrum Master, to look back and reflect on how the team performed to strengthen the way they performed in the near future. The aim of Sprint Retrospective is to build a productive and enjoyable working environment for the Scrum Team.

Feedback typically comes in two ways during a retrospective: the facts and the feelings. Typically, facts are objective and measurable. And, in general, feelings are subjective and more difficult to quantify. There is an appropriate approach named ‘Sad, Mad, Glad‘ that can contribute to this event better. Ben Linders introduces that ‘it helps teams to look for things that make them happy, sad, or drive them mad, and to decide how they want to address these things working together as a team‘.

A final step in a retrospective could be to reflect on how well the retrospective process worked, which is sometimes called ‘the Retrospective of Retrospective’. At the end of the Retrospective, a list of improvement tasks will be delivered. And at least one item will be moved to the Sprint Backlog based on the urgency and estimated effort during the next Sprint Planning.

Sprint Overview

Overall, Sprint is a basic process unit of the Scrum framework. And it is also a container for the Scrum events operated by the different roles toward a specific Sprint Goal defined at the beginning of the Sprint. Each sprint processed independently and sequentially will produce a potentially releasable Increment of “Done” product iteratively and incrementally and also revise the Product Backlog based on it. And the capability and working environment of the Scrum Team will continue to improve simultaneously.

Cancelling the Sprint

As mentioned above, a Sprint can be cancelled by the Product Owner only if its Sprint Goal has been obsolete. However, this kind of situation rarely happens and is the last resort. Once the Product Owner decides to cancel a Sprint, there are the activities occurred including:

• assessing the ‘Done’ work if it can become the potentially releasable functionality or increment;
• reviewing the Sprint Backlog with the assessment of work;
• revising the Product Backlog based on completed and incomplete work;
• revising the Product Backlog items to maximise value given the new circumstances；
• Starting a new Sprint or enclosing the project;
• etc.

Summary

1. From the articles or videos about Scrum on the Internet, Scrum has the characteristics of lightweight and simple to understand as stated in the Scrum Guide. Most Scrum introduction videos can roughly explain the scrum process in five minutes. But at the same time, different to understand, they did not talk about too many workflow details and solutions to various situations in practical applications. Even in the Certified Scrum Master training courses, considering the practical application, I still have a lot of confusion. On the other hand, this is one of the basic principles of agile. Each business activity or project is unique, and there is no method or framework that can fit a specific activity or project 100 per cent. As the term ‘Empiricism’ advocated by Scrum, it is appropriate to find a solution suitable for corporate activities and projects through practical learning and experience.
2. It needs to be clear that the application of Agile frameworks such as Scrum, is a tool for organisations or project teams to better achieve their goals, while is not the goal itself. Just like Ken Schwaber said: ‘Scrum is not a methodology, it is a pathway’.
3. I personally see Scrum as a phased target management framework. It defines goals for each Sprint and achieves the overall goal through accomplishing each phased goal sequentially. And each Sprint provides a degree of flexibility without conflicting to the goal, which allows the development team to leverage the scope and quality of products better. On the other hand, this phased implementing method has greatly reduced the risks from many factors, such as changes in customer’s needs and changes from the marketplace and other conditions. This reflects the first and second items of Agile principles well.
4. In each sprint, the Scrum Master does not participate in a specific event as the main identity, whereas he or she facilitates the entire Scrum process. As a servant leader, the main job of the Scrum Master is to build the work of the entire team on three pillars and helps every member continuously focus on the five values during the work process in order to achieve both product and team improvement. He is the soul of the Scrum team.