Scrum

Scrum is a simplified project management framework that allows for fast application development. Scrum is also referred to as Agile project management. Scrum uses a cross-functional approach, bringing together technical and business resources, including end users who often have a point of view that is crucial to the development of a final product.

Scrum relies on getting the right set of people together at regular intervals (called sprints) to accomplish small pieces of work. It is built for user input and feedback to reduce risk as work products are built quickly, improved on, and delivered in short cycles. The work that to accomplish is tracked in a list called a backlog. Each work product is defined in a user story that explains what the user must do. 

Here are some examples of application user stories in a scrum project:

• As a bank client, I want to print a PDF file of my bank statement from a mobile app.
• As a parent ordering a child's birthday cake online, I want to pay for my order with Zelle.
• As a gamer, I want to see how much gold I have in my vault.

As a framework for project management and application development, scrum ensures the most value-added stories are developed first, ideas are identified and delivered the first time correctly, and employees and customers are involved in the process, increasing buy-in and satisfaction. 

Scrum is a universally accepted and understood framework. Pega Express^™ uses Scrum to help clients get the most out of a Pega project. Furthermore, the Pega Platform^™ is designed to be more effective in a scrum environment. Unlike methodologies such as waterfall project management, Scrum is an approach that lets project teams build quickly, respond to change, deploy continuously, and gather feedback easily. Your clients get the most out of Pega Platform by using Scrum as a project management approach.

There are a number of key roles in a scrum team. Two are leadership roles; the Product Owner who represents the business, and the Scrum Master who facilitates the team.

Here is what each of these roles do:

Product Owner:

• Represents the business and serves as a single point of contact for business decisions
• Manages the product backlog
• Sets stakeholder expectations
• Sets priorities for the scrum team’s work
• Answers questions from the scrum team and clarifies details
• Accepts or rejects user story completion

Scrum Master:

• Removes impediments and barriers for the team
• Runs the daily stand up call and sprint ceremonies
• Is fully dedicated to the team as Scrum Master
• Teaches Scrum and coaches team members on the framework
• Facilitates conversations as required
• Drives software development best practices
• Encourages the Product Owner and development team to collaborate

A sprint is a time-boxed cycle of work, lasting up to four weeks, in which the team builds a deliverable. Sprints are consistent in length throughout the project, and as a sprint ends, the next one starts, delivering a new increment. Multiple scrum events occur within each sprint. Each event helps the team inspect and adapt to what is built.

Scrum events include:

• Story Refinement and Estimation – Provides time to review user stories for size and completeness
• Sprint Planning –  Allows the Product Owner to prioritize user stories in the current sprint
• Daily Scrum – Occurs daily so that the project team can meet and discuss their progress
• Sprint Review – Gives the project team a chance to review what has been built in the current sprint
• Sprint Retrospective – Gives the project team a chance to share feedback on what to change in the next sprint, based on what went well in the current sprint or what can improve

The product backlog is a prioritized list of all the features and requirements necessary to deliver the goal or vision. It serves as a to-do list for the team. The backlog, as a list of items, may evolve throughout a project's lifecycle. The Product Owner is responsible for prioritizing items in the backlog. The backlog itself is composed of user stories, units of work associated with a Minimum Lovable Product (MLP) release. You can create backlogs in a backlog management tool such as Pega Platform^™ Agile Studio.

While not considered a scrum event, backlog refinement is key to a successful scrum delivery. Backlog refinement is the process of tending to and adding details to clarify user stories in your backlog. Backlog refinement fills out the detail in user stories to the point where they can be understood and prioritized by the Product Owner. 

Story refinement and estimation sessions are held frequently. The Business Architects, Product Owner, testers, and developers attend these sessions.
During story refinement and estimation meetings, the team:

• Confirms the development team understands the user stories that are ready for estimation and that the user stories meet the Definition of Ready (DoR), the criteria to determine whether a story is complete.
• Allows the development team to size the effort required to configure and test the user story to meet the criteria set out in the Definition of Done (DoD),  the criteria to determine whether a story is development complete.
• Sizes the story by using story points (small = 1, very large = 13) so that the Project Owner can consider the story at the next sprint planning session.

For more information about sizing and estimating stories with story points, see the Pega Academy topic Getting Stories Ready.

Sprint planning occurs just before the next sprint starts and is scheduled as a regular meeting. Sprint planning is a scrum ceremony where the Product Owner presents the prioritized user stories to the team to be discussed. The team confirms their understanding of the user stories and agrees which they can include it in the sprint.  

Activities that take place include:

• Product owner shares each user story in detail
• Team members ask questions to ensure they understand the story details
• Technical team members help identify any dependencies (dependent user stories)
• As a group, the team confirms which user stories to include
• The team agrees on the best sequence in which to build the stories

Sprint capacity determines the number of stories you can take into the sprint. The sprint capacity is calculated by the development team in collaboration with the test and technical leads. The team determines the number of story points to target in the next sprint. If the number of stories (based on story points) proves to be too challenging, the team can reduce the number at the next sprint planning session. If the team has the capacity to accomplish more story points in a sprint, the team can increase the number of stories.

Over time, the number of story points the team delivers during each sprint must stabilize and form what is known as sprint velocity.

There are two kinds of progress reviews, informal Playbacks, and more formal Sprint Reviews.

Playbacks

Playbacks frequently occur throughout a sprint as informal opportunities for developers to share progress and show the Product Owner what the team accomplished. There is no need to wait until a deliverable is done. By sharing updates at regular intervals, your team can gather feedback and approval from the Product Owner throughout the sprint on work as it is completed. 

Sprint Review

A Sprint Review is a formal session organized by the Scrum Master. The review is scheduled towards the end of the sprint to showcase all development work completed in the sprint. A Sprint Review includes a walkthrough of the user story and confirmation that the story adheres to the definition of done. Then, the Product Owner and business representatives view a demo of the functionality that developers built during the sprint. 

The Scrum Master is responsible for scheduling these dedicated review sessions for each sprint, with a reserved room and access to video conferencing tools. Attendees include the project team, Product Owner, test lead, and Scrum Master. It is common to invite business subject matter experts who support the project.

The Sprint Retrospective is a meeting set up by the Scrum Master at the sprint's conclusion. The Sprint Retrospective provides team members with an opportunity to share:

• What went well in the sprint from a process point of view
• What can improve before the next sprint begins 

Sprint Retrospective attendees must include the project team, the Scrum Master, the Product Owner, and the test team leads. The Scrum Master owns action items coming out of the retrospective to improve subsequent sprints.

Your program may have more than one scrum team delivering application solutions and projects at any one time. If there is commonality and opportunity to re-use solutions between these different scrum teams, you may want to establish a Scrum of Scrums. This is a meeting to support coordination and communication between scrum teams to maximize outcomes, such as streamlining the testing and reuse designs. Each scrum team nominates a member of their team to participate. The Scrum of Scrums ensures alignment of key architectural decisions and sprint planning goals while identifying opportunities for re-use.

Check your knowledge with the following interaction.