Breakdown of Scrum Methodology in Agile Project Management

 

Scrum promotes transparency, inspection, and adaptation by focusing on continuous improvement, requirements flexibility, user involvement, and delivering quality products. Scrum aligns with the values and principles of the Agile Manifesto, which gives importance to people, communication, the product, and flexibility. Successful use of Scrum depends on the team becoming more proficient in practicing the values of commitment, focus, openness, respect, and courage.

This post outlines the main principles of the scrum project management method.

Scrum Roles

	Scrum Master Facilitates Scrum implementation in the team. Ensures conduct of all Scrum events in a timebox. Helps in removal of impediments to progress. Shields the team from external interference. Maintains the Sprint Burndown Chart. Is a facilitator not a manager.
	Product Owner Understands customer requirements and explains to developers. Defines all the product features. Is responsible for prioritizing product features in Backlog. Maintains the Product Backlog. Ensures the team is working on highest valued features.
	Developers Include a team of 5-9 people. Are cross-functional with necessary skills. Are accountable for the assigned task. Define tasks and assignments within a Sprint. Are self-organizing and self-managing. Plan for Sprint and maintain the Sprint Backlog. Conduct the Sprint Review.

Scrum Events

	The Sprint Typically lasts between 01 and 04 weeks. Cycle of development in which actual work is done. Goal should not be changed during the Sprint. Container event which includes the other Scrum events. Goal is achieved by meeting the definition of 'Done'.
	Sprint Planning Product backlog is prepared prior to meeting. Conducted at the start of each Sprint. Timeboxed for up to 08 hours maximum for a 01 month Sprint. Attended by the entire Scrum Team. Review the Product Backlog and Product Goal. Team selects Backlog items committing to complete. Product Owner is available for questions. Tasks are created / assigned, and Sprint Backlog is generated. The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them are referred to as Sprint Backlog. Developers plan the work necessary to create an Increment that meets the Definition of Done. Work decisions should be made at the team level without domination by Scrum Master or supervisors. Developers decide how to turn Product Backlog items into Increments of value.
	Daily Scrum Held every day during a Sprint for 15 minutes maximum. Usually conducted standing in front of Task / Kanban board. Purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting upcoming planned work. Attended by all the developers at same place and time. Every developer answers 03 questions during the meeting: “What have I done since last daily scrum?” “What will I do before the next daily scrum?” “What obstacles are impeding my work?” Opportunity for developers to synchronize their work.
	Sprint Review Conducted at the end of each Sprint, before the Sprint Retrospective. Timebox of up to 4 hours. The Scrum Team presents the results of their work to Product Owner and stakeholders. Purpose is to review the outcome of Sprint, progress towards the Product Goal, and adapt the Product Backlog to include new insights. Functionality not “Done” is not shown during Sprint Review.
	Sprint Retrospective Conducted for up to 3 hours at the end of each Sprint, attended by the Scrum Team. The team reviews questions like what went well during the Sprint and what can be improved? Purpose is to plan ways to increase quality and effectiveness.

Scrum Artifacts

	Product Backlog A transparent and ordered list of all the product features. The single source of work for the Scrum Team. Product Owner is responsible for managing and prioritizing the list with the help of Developers. The list is continuously updated as the project progresses and the user requirements are more clear. Product Backlog is refined by breaking down and further defining Product Backlog items into smaller more precise items.
	Sprint Backlog The set of Product Backlog items selected as per the priority and team velocity for the Sprint (what), and an actionable plan for delivering the Increment (how). A forecast by Developers about what will be in the next Increment. Sprint Backlog is updated during Daily Scrum as more is learned. The sprint backlog ONLY contains prioritized, pointed, and sufficiently defined user stories. ALL user stories must be in “Ready” status for immediate work. Remove all user stories which don’t meet the minimal sprint requirements.
	Increment Working product functionality at the end of each Sprint. Sum of all the Product Backlog items meeting the Definition of Done during a Sprint and the Increments of previous Sprints. At the end of a Sprint, work that did not meet the Definition of Done is returned to the Product Backlog. The increment must be verifiable and usable to provide value. The sum of increments is presented during Sprint Review meeting.
	Burndown Chart Chart showing how much work is remaining in a Sprint. Calculated in hours remaining. The x-axis represents time and the y-axis refers to the amount of work left to complete. Do not use partial story points — only account for actually completed user stories. Slight deviations from expected results are normal. Assess deviations during a retrospective. Maintained and updated by the Scrum Master daily.
	Kanban / Task Board White Board containing backlog items / tasks written on cards and categorized in columns including: To Do, In Progress, To Be Tested, Completed etc. Daily Scrum meeting typically held around the task board. It is visible to everyone. The Kanban board, team agreements, and metrics are transparent and visually posted.

Scrum Process

Glossary of Terms

User Story	It is a very high level definition of what the customer wants the system to do. Each story is captured as a separate item on the Product Backlog. Large user stories indicate they are poorly written and should be rewritten and re-estimated. Each user story is independent from other stories. Template: As a <User> I want <function> So that <desired result>. Example: As a user, I want to print a recipe so that I can cook it.
Story Points	A simple way to initially estimate the level of effort which may be required to complete a particular user story or a task. Story points are a relative measure of the feature difficulty, which is usually scored on a scale of 1-10, where 1 is very easy and 10 is very difficult. Teams should be trained on how to estimate user stories. Teams should initially use one of the well defined estimating practices. The entire team should be involved in the estimation.  Example: “Send to a Friend” feature on web page may be given 02 Story Points, and “Shopping Cart” feature may have 09 Story Points.
Team Capacity	Team Capacity = No of Teammates x (Productive Hrs x Sprint Days) Example: Team Size is 4, Productive Hrs are 5, Sprint Length is 30 days Capacity = 4 x (5 x30) = 600 hours NOTE: Account for vacation time during the Sprint.
Velocity	The rate at which team converts items to “DONE” in a single Sprint, usually calculated in Story Points. Track velocity and obtain a trend over several sprints. Stabilized velocity is a positive trend; it indicates the team is performing consistently.