Agile Process Scrum

           Scrum is something like a framework that is used by teams/organizations to manage their work. Scrum implements the principles of Agile as a concrete set of artifacts, practices, and roles.

     The above mention diagram is showing the life cycle of the scrum. The entire life cycle is running in a exact time period and it is called the sprint.

Product backlog:

In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric. The owner of the Scrum Product Backlog is the Scrum Product Owner. The Scrum Master, the Scrum Team and other Stakeholders contribute it to have a broad and complete To-Do list. Working with a Scrum Product Backlog does not mean that the Scrum Team is not allowed to create and use other artifacts. Examples for additional artifacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, these artifacts do not replace the Scrum Product Backlog but complement and detail its content. Given below is an example for to do List.

 

Sprint Planning and Sprint Backlog:

       Sprint planning is a time boxed working session that lasts roughly 1 hour for every week of sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint. Sprint planning is a collaborative effort involving a Scrum Master, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment. Ensure all sprint candidates meet the team’s definition ready. In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state. Given below is a picture of sprint planning.

 

       The sprint backlog is a list of tasks identified by the Scrum team to be completed during the scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete. It's critical that the team selects the items and size of the sprint backlog. Because they are the people committing to completing the tasks, they must be the people to choose what they are committing to during the Scrum sprint. The sprint backlog is commonly maintained as a spreadsheet, but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.

Sprint Execution and Daily Scrum:

The period of time during which the task-level work is performed by the development team to complete the features committed to during sprint planning.

After Sprint Planning, the Team gets to work and meets every day for the Daily Scrum. All team members working on the Sprint Backlog need to attend and should stand up to help keep the meeting short (no longer than 15 minutes). During the Daily Scrum, each Team member answers three questions.

• What did I do yesterday that helped the Team meet the Sprint Goal?
• What will I do today to help the Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Team from meeting the Sprint Goal?

Sprint Review:

In scrum each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software. So at the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint. Participants in the sprint review typically include the product owner, the Scrum team, the Scrum Master, management, customers and developers from other projects. During the sprint review, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it's more important that they achieve the overall goal of the sprint.

Potentially Shippable Product:

     A Potentially Shippable Product is the sum of the Product Backlog Items delivered each Sprint. Delivering Potentially Shippable Product each Sprint is fundamental to the Scrum because when work is divided into simple pieces it can be finished in a short iterations.

Key features of Scrum are:

• High visibility of progress.
• Regular feedback from customer.
• Predictable rhythm.
• Measurable productivity (via burn down, velocity, etc.).
• Cross-functional, self-organizing teams.
• Inspect and adapt.
• Low bureaucratic overhead (meetings, documentation, etc.).
• Emphasis on face-to-face
• Project can respond easily to change.
• Problems are identified early.
• Customer gets most beneficial work first.
• Work done will better meet the Đustoŵeƌs’ needs.
• Improved productivity.
• Ability to maintain a predictable schedule for delivery
  
  Disadvantages of SCRUM
• Agile Scrum is one of the leading causes of scope creep because unless there is a definite end date, the project management stakeholders will be tempted to keep demanding new functionality is delivered.
• If a task is not well defined, estimating project costs and time will not be accurate. In such a case, the task can be spread over several sprints.
• If the team members are not committed, the project will either never complete or fail.
• It is good for small, fast moving projects as it works well only with small team.
• This methodology needs experienced team members only. If the team consists of people who are novices, the project cannot be completed in time.
• Scrum works well when the Scrum Master trusts the team they are managing. If they practice too strict control over the team members, it can be extremely frustrating for them, leading to demoralization and the failure of the project.
• If any of the team members leave during a development it can have a huge inverse effect on the project development

Given below is some Differences between kanban and the scrum.

Wathsara Wishwantha Daluwatta