Importance of Sprint Backlog in a Scrum Project
The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during Sprint Planning Meeting.
What is your answer
The Product Owner on a project, on which you are the Scrum Master, has
identified disaster situations, such as earthquakes and tsunamis, as
potential risks to the underwater transnational communication sea link.
The Stakeholders have suggested that steps to safeguard the foundations
of the ocean infrastructure be taken at the earliest, and also have
recommended that a contingency reserve be created, which could be used
in case of disaster situations. This is an example of:
a) Risk Mitigation.
b) Risk Prioritization.
c) Risk Avoidance.
d) Risk Assessment.
Scrum processes address the specific activities and flow of a Scrum project. In total there are 19 processes which are grouped into five phases.
Please take a look at these processes and the activities listed under to them in order to understand the flow of a Scrum Project better.
Initiate
Create Project Vision—in this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.
Identify Scrum Master and Stakeholder(s)—in this process, the Scrum Master is identified using specific Selection Criteria.
Form Scrum Team—in this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.
Develop Epic(s)—in this process, the Project Vision Statement serves as the basis for developing Epic(s). User Group Meetings may be held to develop Epic(s).
Create Prioritized Product Backlog —in this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
Conduct Release Planning—in this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.
Plan and Estimate
Create User Stories—In this process User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.
Approve, Estimate, and Commit User Stories—In this process the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.
Create Tasks—In this process the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.
Estimate Tasks—In this process the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.
Create Sprint Backlog—In this process the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint.
Implement
Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.
Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.
Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.
Review and Retrospect
Convene Scrum of Scrums—In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved.
Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.
Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.
Release
Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.
