What is Scrum Framework?

Scrum is a framework that is designed for delivering software products. It comprises three roles, three artefacts and five events:

Roles:

1. Product Owner

2. Development Team

3. Scrum Master

1. Artefacts:

   1. Product Backlog

   2. Sprint Backlog

   3. Increment

2. Events:

   1. Sprint

   2. Sprint planning

   3. Daily Scrum

   4. Sprint Review

   5. Sprint Retrospective

These basic elements provide a structure for managing the decisions, risks, actions and uncertainties that come with building and maintaining a software product. Scrum is deliberately incomplete, in that it goes no further than specifying who is accountable for what, with a basic structure to ask the right questions. Once established, as Scrum team will complete the process by adding the business- and technology-specific processes that make sense for their work. Over time, a mature team will evolve a bespoke process based on the core Scrum framework that is as efficient and effective as their skills and imaginations allow.

Scrum rules

There are a number of mandatory elements and rules that Scrum establishes in order to direct attention to sub-optimal ways of working. These include:

• Ensuring that the basic elements are in place (roles, events, artefacts).

• Creating a potentially shippable increment in 30 days or less, with no outstanding testing, integration, documentation or other work.

• Having a clearly defined product with one single product owner.

• All of the events have a maximum permitted duration (called a timebox).

The purpose of these rules is to prompt questions of the underlying process, so that improvements to the delivery teams's ability to deliver may be identified. For example, if the team does not have a product owner, then it is useful to question whether anyone is accountable for realising a return on investment for the substantial costs of funding the team each sprint. If a team is unable to deliver a potentially shippable product increment in less than 30 days, it may draw attention to the structure of the codebase or a need to automate testing and deployment. In most cases, figuring out how to adhere to the Scrum rules will improve the underlying business. If not, it may be that you are not doing the type of complex software product development that Scrum was designed for, in which case Kanban would be a useful alternative to consider.