Scrum

Scrum Process Framework

Scrum is a lightweight agile project management framework mainly used for software development. It describes an iterative and incremental approach for project work.

Concept of Sprint

Scrum suggests project to progress through a series of sprints. Sprints are timeboxed iterations that is no more than a month long, most commonly two weeks (roughly 1-4 weeks). Sprints are best to have consistent durations throughout a development effort. A new sprint starts immediately after the conclusion of previous sprint.

Scrum Roles

Scrum roles include regular participation of:

1. 1. 1. 1. Product Owner - Holds the vision of the Product

2. Scrum Master - Helps the Team best use scrum to build the Product

3. Development Team - Builds the product

Scrum Workflow

The chart below showcases the basic flow followed in Scrum process, explaining the roles and their involvement in the process:

Tool used: Atlassian JIRA and Confluence

We normally use Atlassian JIRA to track the development progress and Atlassian Confluence for documenting project artifacts. While explaining the scrum process, you will find below various screenshot from JIRA explaining the process and tools together.

Defining requirements in Scrum

Create issue: User Story with Acceptance criteria

Large features of the Project is broken down into user stories. User stories are used to defined any task to be completed. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >

An acceptance criteria is defined while defining any story in JIRA which is shown in the screenshot below.

Defining Labels:

1. Feedback
   
   During the development phase itself, close collaboration is required among Team members and Product Owner. So to ease these feedback sessions, every progress about a task is roofed under a single User Story. Feedback_required is used as a label to easily filter issues in the Kanban board and clients can provide feedback in the comment section.
   
   

2. Tracking Change requirements:
   
   As we follow the agile process for development, we know the the changing business environment might result in some changes in the initially defined requirement. In such cases it becomes essential to track those changes. This tracking is also done in JIRA by introducing Labels in issues. In the screenshot below, a label “change_requirement” has been introduced to group the feature with the changes:

Scrum Artifacts

Scrum Artifacts include the following:

1. Product Backlog
   
   The Product Backlog is an ordered list of features in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, its content, availability, and ordering. The Product Backlog evolves as the product and the environment in which it will be used evolves. Below is the screenshot showing Product backlog along with sprint backlog:
   
   
   
   

2. Sprint backlog
   
   The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment Only the Development Team can change its Sprint Backlog during a Sprint. Below is the screenshot from tool “JIRA” showing the progress in active Sprint 1.
   
   
   
   

3. Burndown chart
   
   Progress on a Scrum project can be tracked by means of a release burndown chart. The horizontal axis of the sprint burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers - story points, ideal days, team days and so on. Below is the attached image of a burndown chart that was generated based on the progress made in sprint 1:
   
   
   A key metric in Scrum called Velocity is used to  measure the amount of work a team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

4. Increments
In Scrum, each sprint is required to deliver a potentially shippable product increment which is defined as increments. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

Scrum Ceremonies

Scrum ceremonies include the following:

1. Sprint Planning (Team in collaboration with Product Owner)
   During the sprint planning meeting, tasks to be performed during the sprint is planned.  The product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level User Story of the product backlog into the more detailed tasks of the sprint backlog. This plan is created by the collaborative work of the entire Scrum Team.
   
   

         2. Daily Scrum/Standup

The Daily Scrum is a 15-minute time-boxed event for the Development Team to inspect progress toward the Sprint Goal and create a plan for the next 24 hours. During the meeting, the Development Team members explain:

• 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?

3. Sprint Review (Informal Demo of development to PO/stakeholders and feedback sharing)

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

4. Retrospective (Team reflects on how they are doing and to find ways to improve)

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

Managing release in JIRA

A version is a set of features and fixes released together as a single update to the application. Assigning issues to versions helps to plan the order in which new features (stories) for the application will be released to the customers. In JIRA Software,we can view our issues according to which version they belong to. We can also drag-and-drop issues into a version to assign them to it, which we should do before we start work on the issues. This helps us plan our upcoming versions, which may span multiple sprints.

Change request in Scrum

How to manage change request in ongoing Sprint?

1. When to not add change request in current sprint?

• PM, after consultation with relevant stakeholders, can decide whether the change can wait until next Sprint. If the priority/ business value of the change request is not higher than the tasks in the current Sprint backlog then it can wait until later.

• If it's a big change, but isn't totally disruptive to the current sprint's work, then certainly you should add it to the backlog for future planning and implementation.
  
  

2. When to add change request to current sprint?

• If the stakeholders agree to trade-off the change request with an existing item in the current sprint then we can swap that item with the change request. (Provided they have the same estimates)

• If it's a small enough change that won't significantly impact the team's overall deliverables for the sprint, just add it in - either as a new success criteria or a new story. Discuss this with the team during one of the daily stand-ups to ensure that they understand what the change is and why it’s needed. (Not a recommended action as per Scrum practices)

When to cancel the current sprint?

• If the existing items in sprint does not add high business value, it may require ending the current Sprint and starting a new one.

How to adapt to changes?

• Select the Sprint cycle duration based on the nature of client and the frequency of change request.

• Change request needs to be properly prioritized and estimated.

Search in JIRA

We can easily search for issues in JIRA. Navigate to Issues (in header) > Search for issues, then enter your search criteria. The search results can also be saved, exported and used for reporting purposes. We can also extract reports using Search for Confluence.