Scrum Framework

Scrum is not just a process which provides a series of sequences that will help you to produce a high-quality product on time and within a budget. Rather, Scrum is a process framework that allows addressing complex problems to deliver products of the highest possible value. At the beginning of 1990, when Scrum was in its infancy, organizations started using the Scrum framework to build the products using various processes and techniques.

Basically, Scrum is an easy, people-centric framework based on the values of:

• Commitment
• Openness
• Courage
• Respect
• Focus

The Scrum framework consists of the Scrum teams with associated Scrum Roles, Scrum Ceremonies, Scrum Artifacts, and Scrum rules. Each component within a Scrum framework has specific grounds and is a key factor to Scrum’s success, whereas the Scrum rules tie the ceremonies, roles, and artifacts together to govern the relationships between them.

Roles in Scrum

Scrum Framework consists of three Scrum Roles-

• Product Owner
• Scrum Master
• Development team

The Product Owner (PO) mainly concentrates on maximizing the value of the product and the teamwork. The entire organization respects PO’s decisions. The PO is the only person who manages the Product Backlog. This includes:

• Mentioning Product Backlog items clearly.
• Prioritizing the Product Backlog items to achieve project goals.
• Optimizing the value of the teamwork.
• Ensuring the Product Backlog is transparent to all.
• Ensuring that the team understands the Product Backlog items.

The Scrum Master is a Servant leader of the Scrum team. He or she guides the team and the Product Owner ensures that the team members are implementing all the Agile practices properly. The Scrum Master is not only responsible for addressing all the issues encountered in the Agile development process, but also helps the business, product owner, team, and individuals to achieve a target.

The Development team in Scrum is cross-functional, a collection of people who can define, build, and test the required product. The development team size is of 5-9 people and must have all the skills required to produce good quality software. The Development team is a self-organized team that determines the best way to reach out to a solution during product development.

Scrum Rules

Presenting a list of Scrum rules, that need to be followed within a Scrum framework in software development:

• Sprint related rules:

  • Sprint length should be long enough to deliver meaningful chunks of work and short enough to ease the planning process.
  • Every Sprint includes Sprint Planning and Sprint Planning meeting must be time-boxed to 2 hours or a week of Sprint length.
  • Every Sprint is of the same length.
  • Every Sprint should be of 4 weeks or less in duration.
  • Potentially shippable product’ must be an outcome at the end of each Sprint.

• Product Backlog related rules:

  • All the Product Backlog items (PBI) mentioned in the Product should be related to the same product.
  • Two PBIs can’t have the same position in the Product Backlog.
  • PBIs are conveyed in the form of user stories.

• Scrum rules related to the team members role:

  • As a team member, one should not miss any Scrum Events.
  • As a team member, he/she should work collaboratively to follow the ‘Definition of Done’.

• Scrum rules related to the Scrum Master (SM) role: 

  • As a Scrum Master, he or she has authority on following the right way to implement the Scrum process.
  • Scrum Master has to ensure the timeboxes within a team.
  • As a Scrum Master, he or she removes impediments that the team is facing and helps in meeting the ‘Definition of done’.

• Scrum rules related to the Product Owner (PO) role:

  • PO can put defects at the top of the product backlog.
  • PO always allows the team members to choose a number of PBIs to do in one Sprint.

Scrum Events and Scrum  Artifacts

Scrum ceremonies are time-boxed events that create regularity.  These are the events that form Scrum.

The Scrum ceremonies are:

1. Sprint: 

Sprint is called the heart of Scrum. Generally, it is of a month’s duration or less, till the potentially shippable product increment is formed. A new Sprint can be started immediately, once the previous Sprint ends.

2. Sprint Planning Meeting:

In this meeting, the objectives of the forthcoming Sprint are defined. This meeting is held towards the start of each Sprint. The Product Owner, Scrum Master, and the team members can be a part of the Sprint Planning meeting.

3. Daily Scrum: 

Daily Scrum is also called the Daily Stand-up meeting. The purpose of the daily Scrum is to know the answers to the three questions about what one did yesterday, is doing today, and what the obstacles are.

4. Sprint Review meeting: 

This meeting is held once each Sprint is finished. In this meeting, the team demonstrates the work that they have produced during the Sprint. This meeting can be attended by the team members, the Scrum Master, the Product Owner, and the Stakeholder.

5. Sprint Retrospective: 

This is the last event that wraps up a Sprint cycle. It is held for the teams to share their knowledge earned to enhance the team’s interaction for upcoming Sprint cycles.  

The Scrum Artifacts are the objects that are produced as a part of Scrum. The 3 Scrum artifacts are:

1. Product Backlog: The Product Backlog is an ordered list of user requirements. It is the single source that can be referred in case of any changes needed to reflect in the product.
2. Sprint Backlog: Sprint Backlog is created by the team members during the Sprint Planning meeting. This backlog contains a list of user stories or features that can be implemented during Sprint iterations.
3. Sprint Burndown chart: Sprint Burndown chart is used to track the progress of a Sprint against a Sprint Backlog. Burndown charts are the graphical depiction of the percentage of items completed.

Definition of Done

Earlier we already mentioned ‘Definition of Done’ and its importance in meeting Sprint goals. Let us now discuss in details.

When a Product Backlog item or an Increment is declared as ‘Done’, every team member should first understand the meaning of ‘Done’ in a Scrum context. This may largely vary from one team to another. But the members ought to have a shared understanding of what it means for a work to be deemed as complete’. This is primarily intended to ensure transparency. This is the definition of ‘Done’ for any Scrum Team and is mainly used to assess when work is complete on the product Increment.

The same definition of ‘Done’ directs the Development Team in understanding how many Product Backlog items can ideally be selected during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that align with the Scrum Team’s current definition of ‘Done’ Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, therefore a Product Owner may prefer immediately releasing it. If the definition of ‘Done’ for a particular increment is a part of the standards or guidelines of the development organization, all the Scrum Teams should mandatorily follow it. If ‘Done’ for an increment is not a convention of the development organization, the Development Team of that Scrum Team must define a definition of 'Done' which is suitable for the product. If there are a number of Scrum Teams working on the system or product release, the Development Teams of all these Scrum Teams should clearly define the definition of ‘Done’ It should be noted that this should be a ‘mutual’ definition.

The increments are cumulative and thoroughly tested, ensuring that all the Increments work together.

Throughout the project, as the Scrum Teams progressively mature, their definitions of  'Done' are expected to expand in order to include more criteria for higher quality. New definitions, as used, may uncover work to be done in previously 'Done' increments. Any one product or system should have a definition of  'Done' that will be considered as a standard for any work done on it.

The team in Scrum is analogous to a boat, always ready to travel in whichever path it is pointed to. The Product Owner is the helmsman, ensuring that the boat is following the correct way, and the Scrum Master is the main repairman, making sure that the team is following all the Scrum ceremonies and getting things done.