What is Scrum?

What is Scrum?

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.It is the most popular agile framework, which concentrates particularly on how to manage tasks within a team-based development environment. Scrum uses iterative and incremental development model, with shorter duration of iterations. Scrum is relatively simple to implement and focuses on quick and frequent deliveries.

Scrum has only three roles: Product Owner, Team, and Scrum Master. These are described in detail by the Scrum Training Series. The responsibilities of the traditional project manager role are split up among these three Scrum roles.

Scrum has five meetings: Backlog Grooming (Backlog Refinement), Sprint Planning, Daily Scrum (15-minute stand-up), the Sprint Review Meeting and the Sprint Retrospective Meeting.

It isn’t individual effort but the best coordination of the team that will determine which way the ball goes.  Instead of a hand-off between individuals as a relay race, the team is working together to get to the goal together.

Scrum (scrum software development)

Scrum is an iterative and incremental agile software development methodology for managing product development.

It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.

It enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members; it encourages daily face-to-face communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn").

Scrum adopts an empirical approach, accepting that the problem cannot be fully understood or defined in one go and focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

Scrum Project Roles, Events and Artifacts

Roles (three core roles)

Product Owner - The Product Owner represents the stakeholders and is the voice of the customer and is accountable for ensuring that the team delivers value to the business.

Development Team - The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (iteration).

Scrum Master - Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.

Product Owner

Responsible for overall project vision and goals.

The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans.

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders to steer the project in the right direction.

Product owners bridge the communication gap between the team and their stakeholders.

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the stakeholders:

•      announces releases

•      organizes milestone reviews

•      educates stakeholders in the development process

•      communicates team status

•      negotiates priorities, scope, funding, and schedule

•      ensures that the Product Backlog is visible, transparent, and clear

•      demonstrates the solution to key stakeholders who were not present in a normal iteration demo

A product owner needs to be able to see from these different points of view. To be effective, it would also be wise for a product owner to know the level of detail the audience needs from him or her.

Development Team

Team is made up of 3- 9 people

•      Can be shared with other teams (but it is better when not)

•      Can change between Sprints (but better when they don’t)

•      Can be distributed (but better when collocated). Most successful when located in one team room, particularly for the first few Sprints.

Cross-functional

•      Possesses all the skills (analyse, design, develop, test, technical communication, document, etc.) necessary to produce an increment of potentially shippable product. It includes members with development & testing skills and business analysts, domain experts, etc.

•      Team takes on tasks based on skills, not just official “role”

Self-managing/Self-organizing

•      Team manages itself to achieve the Sprint commitment. Intensely collaborative.

•      Negotiates commitments with the Product Owner

Scrum Master

The Scrum Master is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences.

The core responsibilities of a Scrum Master include

•      Helping the Product Owner maintain the product backlog in a way that ensures the project is well defined and the team can continually advance forward on the project at any given time

•      Educate team and others involved with the project on Scrum principles

•      Determine the definition of done for the project with input from the entire Scrum team

•      Promote self-organization within the team

•      Remove all impediments to the team's progress, both internal and external to the Scrum team

•      Facilitate team meetings to ensure regular progress

•      Keeps Scrum artifacts visible

What Does the Scrum Master NOT Do?

1. The Scrum Master does not manage the team
2. The Scrum Master does not direct team-members
3. The Scrum Master does not assign tasks
4. The Scrum Master does not “drive the team” to hit its goals
5. The Scrum Master does not make decisions for the team
6. The Scrum Master does not overrule team-members
7. The Scrum Master does not direct product strategy, decide technical issues, etc.

Product Backlog

The product backlog is an ordered list of requirements that is maintained for a product/project. It consists of features, bug fixes, non-functional requirements etc.

The product backlog items (PBIs) are ordered (highest priority item is listed first, next-highest is second, etc.) by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

The product backlog contains the Product Owner's assessment of business value and the Development Team's assessment of development effort, which are often, but not always, stated in story points using a rounded Fibonacci sequence.

These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items.

The size (i.e. estimated complexity or effort) of backlog item is determined by the Development Team, who contributes by sizing items.

Product Backlog DEEP criteria

D- Detailed

E- Emerging

E- Estimated

P- Prioritized

Product Backlog Item (PBI)

Specifies the what more than the how of a customer-centric feature

Often written in User Story form

Has a product-wide definition of done to prevent technical debt

May have item-specific acceptance criteria

Effort is estimated by the team, ideally in relative units (e.g., story points)

Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams

User Stories: Components

A User Story describes functionality that will be useful to a stakeholder of   the system

Problems statements (not part of use cases or really user stories) define the problem being solved by the solution and have the following template:

The problem of:                              What is the problem

Affects:                                             Which stakeholders does it affect

Impact:                                             What is the impact to each stakeholder

A successful solution would:        What business value would be derived from the solution

Use Cases: Describe the flow of events between the user of the system and the system.  Use cases have more detail and tend to be more complete, but do not address the business value or business problem being addressed.  Template:

•         Use Case Name

•         Actor

•         Brief Description

•         Basic Flow

•         Alternative Flows

•         Pre and post conditions

•         etc

User Stories format should be like

As a <role> I can <goal> so that I can <business value>

Splitting stories into smaller stories

Sprint

A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a time boxed effort, i.e. it is restricted to a specific duration.

The duration is fixed by team and product owner in advance for each sprint and is normally between one week and one month, although two weeks is typical.

Factors involved in deciding Sprint length

•         Duration of the project

•         Customers/stakeholders

•         How often can they provide feedback and guidance

•         Scrum familiarity

•         Environment factors

•         The Scrum team

•         Scrum experience and Technical capabilities

Sprint Pre-Planning Meeting

Scheduled to determine user stories for next Sprint

Takes place few days before the end of a Sprint (and start of the next Sprint)

Activities during pre-planning meeting

•      Backlog Grooming

•      Re-prioritize the backlog if required

•      Any User Stories that are no longer relevant to be removed

•      Product Owner walks the team through the items at the top of the Product Backlog

•      Team asks questions and requests clarification to gain clarity on the potential user stories

•      Team identifies any User Stories that will not fit into the Sprint

•      Team ensures Acceptance Criteria is defined for all user stories being considered

Sprint Planning Meeting

Team understands details of what Product Owner has prioritized on Product Backlog

Team decides how much productive time is available during the Sprint

Team decides how many Product Backlog items it can commit to complete during Sprint

Prepare the Sprint Backlog that details time required to do selected work with the entire team

•      Eight-hour time limit for a 30-days sprint (i.e. two hours per week duration)

•      (First four hours) Entire team (Dev.Team, Scrum Master, Product Owner): dialogue for prioritizing the Product Backlog.

•      (Second four hours) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog

Sprint – Definition of Ready

INVEST Model

           
            I- Independent

N- Negotiable

V- Valuable

E- Estimable

S- Small

T- Testable

The Sprint Backlog

Consists of committed PBIs negotiated between the team and the Product 

Owner during the Sprint Planning Meeting

Scope commitment is fixed during Sprint Execution

Initial tasks are identified by the team during Sprint Planning Meeting

Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution

Visible to the team and Referenced during the Daily Scrum Meeting

Sprint Task

Specifies how to achieve the PBI’s what

Requires one day or less of work

Remaining effort is re-estimated daily, typically in hours

During Sprint Execution, a point person may volunteer to be primarily 

responsible for a task however owned by the entire team; collaboration is expected

No changes during Sprint

Once team has committed, no changes

No Changes to Deliverable

–     Once team has committed, there are no changes in the deliverable

–     If something major comes up, Product Owner can terminate the Sprint and start a new one

–     Details and clarifications will emerge during Sprint, but no new work or substantially changed work

No Changes to Sprint Duration

–     Sprint ends on planned date whether team has completed its commitment or not

Product Owner can make any changes to the remaining Product Backlog before the start of the next Sprint

A Sprint can be discarded under unavoidable circumstances

Daily Scrum Meeting

Each day during the sprint, a project team communication meeting occurs. This is called the daily scrum (meeting) (or “stand-up-meeting) and has specific guidelines:

All members of the development team come prepared with the updates for the meeting.

The meeting starts precisely on time even if some development team members are missing.

The meeting should happen at the same location and same time every day.

The meeting length is set (time boxed) to 15 minutes.

All are welcome, but normally only the core roles speak.

During the meeting, each team member answers three questions:

•      What did I do yesterday that helped the Development Team meet the Sprint Goal?

•      What will I do today to help the Development Team meet the Sprint Goal?

•      Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

    

     Following the Scrum meeting, team updates the Product Backlog and Scrum Master updates the Burn down Chart

Task or Story Board

Sprint Review or Sprint Demo

Purpose of the Sprint Review:

Review the work that was completed (if any, planned work that was not completed)

Demo of what’s been built and not a presentation about what’s been built (no Power Points allowed)

Generate feedback which the Product Owner can incorporate in the Product Backlog

Attended by Team, Product Owner, Scrum Master, functional managers, and any other stakeholders

Usually lasts 1-2 hours

Followed by Sprint Retrospective

Sprint – Definition of Done

In Scrum, “Done” is defined as “Potentially Shippable”

Sprint Retrospective

1-2 hour meeting following each Sprint Demo

The Scrum Master or a neutral person facilitates this meeting

Attended by Team, Product Owner and Scrum Master

All team members reflect on the past sprint

Two main questions are asked in the sprint retrospective:

•      What went well during the sprint?

•      What could be improved in the next sprint?

Why Retrospective matter?

•      Accelerates visibility

•      Accelerates action to improve

Sprint Cycle: 2-Week Sprint 

Scrum Reports

Scrum Advantages/ Disadvantages

1. Accelerate Time to Market
2. Early and Continuous Customer Validation
3. Greater Visibility into Project Progress
4. Early Defect Detection and Prevention
5. Risk Reduction and Quality Improvements
6. Improve Team Morale
7. It’s hard
8. Partial Implementation does not give desired results

I hope this agile blogs will be useful for you and you can get knowledge for Agile methodology for both personal and professional activities. I will be also happy to receive any comments; I am always glad to read them.    

If you’re looking for more topics the please write in comment section so that I could help you with some more blogs for your interested topics. Please do not forget to check my new blogs for digital transformation processes.

Don’t forget to subscribe to our blog we will keep sharing useful tips for Agile and Agile Software Development!