Please find highlights from Satya Narayan Dash’s webinar – Practical Scrum Using MS Project Agile – being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations, or there may be additions to expand on concepts. You may watch the on-demand recording of this webinar at your convenience.
If you’re new to agile project management and Scrum, you may be wondering how these approaches work in practice. In this article, we’ll provide an overview of Scrum fundamentals and the Scrum framework, including its roles and artifacts. We’ll also explore how scrum can be applied in Microsoft Project, a popular project management tool, with hands-on examples.
The Fundamentals of Scrum
The Scrum framework, created by Jeff Sutherland and Ken Sparver, has its roots in Japanese inspiration. In 1984, Hirotaka Takuyuchi and Ikujiro Nonaka published a paper called “The New, New Product Development Game,” which introduced the term “scrum” from rugby football. Sutherland and Sparver acknowledged Takuyuchi and Nonaka as the initial publishers of the paper. Scrum is a lightweight framework that helps individuals, teams, and organizations generate value through adaptive solutions for complex problems. Scrum theory is based on empirical process control theory and empiricism, as well as lean thinking. The latest Scrum Guide, released in November 2020, introduced the term “lean” multiple times. The Scrum framework is particularly applicable in the complex domain, where both requirement uncertainty and technological uncertainty are high. However, it is not suitable for the KO domain, where both uncertainties are extremely high.
Empiricism is a key concept in the Scrum framework. It emphasizes that knowledge is gained through experience, and decisions should be made based on what is known. There are three pillars of empiricism: transparency, inspection, and adaptation. Transparency requires that all aspects of the process that affect the outcome should be visible. Inspection involves frequent monitoring of the process to detect any variances. Adaptation involves adjusting the process if the variances are outside acceptable limits. These three pillars of empiricism, also known as TIA or VIA (Visibility, Inspection, Adaptation), are the foundation of the Scrum framework.
The Scrum Framework
The Scrum framework is actually quite simple. A complex problem is translated into an ordered list of items called the product backlog. The Sprint backlog is created from the product backlog in the Sprint planning meeting. The top priority and ordered items will be taken by the team that fit into an upcoming iteration. The iteration is known as a Sprint, which is usually two to four weeks long. It is possible that you might have a one-week Sprint length. As per the Scrum Guide, it is recommended that the Sprint length should be less than a month, or less than or equal to four weeks. Every day, there is a stand-up meeting for 15 minutes called the Daily Scrum or Daily Stand-up meeting, where the execution work is reviewed.
Next, we have a Sprint review meeting, which is held at the end of the Sprint to demonstrate the increment. The demonstration will happen in front of the stakeholders. The stakeholders might accept or reject the increment that is being delivered by the team. An increment is when the item or the work items that have been taken from the upcoming Sprint meet the Definition of Done or the DoD.
What is Backlog Refinement
The Product Backlog is a key component of the Scrum framework. It represents a list of items that need to be completed to solve complex problems. The backlog is constantly refined, in an event called Product Backlog Refinement or Backlog Refinement. During this process, the items in the backlog are ordered according to priority, with high-priority items at the top and low-priority items at the bottom. The high-priority items are clearly defined and granular, while the low-priority items are less granular or coarse-grained. The backlog is centered around the product goal and is used as a guide for the development team to complete the work during the Sprint.
The product owner is a crucial role in the Scrum framework, responsible for managing and prioritizing the product backlog. While anyone can suggest a requirement for the product, only the product owner has the authority to decide what items are added to the product backlog. This includes input from stakeholders, team members, customers, sponsors, and outsiders. The product owner is accountable for ensuring that the product backlog is refined with high-priority and high-order items toward the top of the backlog. This helps to ensure that the team is working on the most valuable items first, and that the product is being developed in a way that aligns with the product vision and goals.
Sprint Planning
During the Sprint planning meeting, the Sprint backlog will be prepared by taking a few items from the top of the product backlog. The team members will decide which items can be taken and who will work on those items. They will also determine how the items will be broken down into individual tasks. The team members are responsible for building the Sprint backlog. The Sprint backlog will have the Sprint goal, which is the objective for the upcoming Sprint of two to four weeks. The team will define what the goal is for the upcoming Sprint, and once the Sprint backlog is finalized, the Sprint can begin.
Daily Scrum
Every day in the Scrum framework, there is a 15-minute Daily Standup meeting that usually takes place at the same time and location, and involves the Scrum Master, Product Owner, and developers. The purpose of the Daily Standup is not to report the status to a project manager, but to collaborate and review progress made the previous day, plan for the upcoming work of the day, and identify any impediments, issues, or risks that may be blocking the team’s progress. After the meeting, the team disbands and continues working until the end of the sprint, which is typically two to four weeks. On the final day of the Sprint, there is a Sprint Review.
Sprint Review
During the Sprint review, team members or developers present the increment they have worked on over the last two weeks to the stakeholders. It is important to note that it is the stakeholders, not just the product owner, who accept or reject the increment. While the product owner is part of the team and is involved in accepting the increment on a daily basis, it is primarily the key stakeholders who formally accept the increment during the Sprint review meeting. It is a common misconception that the product owner solely accepts the results, when in fact, it is a collaborative effort involving the entire team and stakeholders.
Sprint Retro
The last meeting in the Sprint cycle is the Sprint retrospective, where the team members come together to reflect on the previous iteration and discuss potential process improvements for the upcoming iteration or Sprint. During this meeting, the team analyzes what worked well and what didn’t, and collaboratively identifies areas for improvement. The goal of the Sprint retrospective is to continuously improve the team’s performance and efficiency.
Scrum Roles
Now let’s dive into the roles within Scrum. The Scrum team is a unified entity that consists of three roles: the Product Owner (PO), the Scrum Master (SM), and the Developers. Unlike in traditional teams where there may be separate departments such as design, architecture, engineering, testing, or documentation, the Scrum team is an immutable team where everyone is considered a developer. This means that all team members work collaboratively towards the same goal and share responsibility for the success of the project. In this section, we will discuss the specific responsibilities of each role within the Scrum framework.
Product Owner (PO)
- Decides the strategic direction of the product
- Defines the product goal, both short-term and long-term
- Collaborates with stakeholders to ensure that product vision is understood and aligned
- Creates and prioritizes the product backlog
- Accepts or rejects completed work based on the product’s goals and requirements
- Ensures that the product meets the needs of its users and customers
- Acts as the head of the team
Scrum Master (SM)
- Owns the Scrum process and ensures that it is properly implemented
- Facilitates Scrum events such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
- Removes any impediments that are preventing the team from delivering the Sprint Goal
- Protects the team from external interruptions or distractions
- Encourages the team to be self-organizing and cross-functional
- Inculcates the values of Scrum, such as transparency, courage, and openness
- Acts as the heart of the team, serving as a leader who ensures that the team is productive and happy
Developers
- Create the Sprint backlog based on the priorities set by the Product Owner
- Collaborate with each other to design, build, and test product increments
- Adhere to the Definition of Done (DoD) for each increment of work
- Estimate and communicate progress towards the Sprint Goal during Daily Scrum meetings
- Continuously inspect and adapt their process to improve their work
- Work collaboratively with the Product Owner and Scrum Master to ensure that the product increment meets the product goal
- Act as the body of the team, working together to bring the product vision to life
By understanding the roles and responsibilities of each member of the Scrum team, it becomes clear how everyone works together to deliver valuable product increments. The Product Owner sets the strategic direction, the Scrum Master ensures that the process is followed and the team is productive, and the Developers work together to create product increments that meet the product goal. Together, they form a unified and highly effective team that is able to deliver high-quality products to customers.
Summary of the Scrum Roles, Events and Artifacts
In addition to the roles we’ve already discussed, Scrum also has a set of events and artifacts that are essential to its framework
The Scrum framework comprises a set of events, artifacts, and commitments that help ensure the creation of high-quality products. Let’s look at a summary of the components of the scrum framework.
Scrum Roles, Events and Artifacts
Events
- Sprint: A time-boxed period of one month or less during which a “Done”, usable and potentially releasable product Increment is created.
- Sprint Planning: A collaborative event where the entire Scrum team plans the work for the upcoming Sprint.
- Daily Scrum: A daily 15-minute time-boxed event where the development team synchronizes activities and creates a plan for the next 24 hours.
- Sprint Review: A collaborative event where the Scrum team and stakeholders review the product Increment and adapt the Product Backlog as needed.
- Sprint Retrospective: A collaborative event where the Scrum team inspects itself and creates a plan for improvements to be enacted during the next Sprint.
Artifacts
- Product Backlog: An ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
- Sprint Backlog: A plan that contains the set of Product Backlog items selected for the Sprint, plus the plan for delivering the product Increment and realizing the Sprint Goal.
- Increment: The sum of all the Product Backlog items completed during a Sprint, integrated with all the previous Increments, and evaluated to ensure that it meets the Definition of Done.
Some practitioners also consider the Burndown Chart, a graphical representation of work left to do versus time, as an artifact.
Commitments
- Product Goal: A commitment to the objective that the product or product increment should achieve.
- Sprint Goal: A commitment to the objective that Sprint should achieve.
- Definition of Done: A shared understanding of the criteria that must be met for each Product Backlog item to be considered “Done” and to ensure transparency.
These events, artifacts and commitments are the building blocks of Scrum and help to ensure that the team is always moving in the right direction towards the creation of a high-quality product.
Conclusion
In conclusion, Scrum is a framework that helps teams deliver value in a complex environment with changing requirements. To achieve this, Scrum provides several artifacts, such as the product backlog, Sprint backlog, and increment, which are all connected by clear commitments. The product goal, which is set by the product owner, drives the Sprint goal, which in turn drives the features and stories to be completed in the upcoming Sprint.
The definition of done is a checklist of items that ensure the quality of the increment, and it is prepared by the team during the Sprint planning meeting. The release goal, if there is one, drives the Sprint goal, and not the other way around. By focusing on these commitments and values such as openness, courage, and focus, Scrum teams can stay on track and deliver value consistently.
As Satya puts it, it is important to remember that requirements do not drive the goals, but rather the goals drive the requirements. This shift in mindset can help teams overcome the challenges of complex projects and stay focused on delivering value to their customers.
