Simply put, Scrum is a software development methodology that is based on self-organizing teams working with a product owner to make software shippable as soon as possible with continuous iterative improvements to the system, team, and process.
The Scrum process is anchored by the following standard fundamental elements: a backlog list, the team, owner, stand-up, planning sessions, and retrospectives. The role of the Scrum Master is to ensure that all elements are functioning properly, eliminate obstacles, and tackle any unknowns head-on. Additionally, the Scrum Master tracks the velocity (using a burn-down chart) within the iteration, capacity per iteration, capacity per person, and ensures that project and company requirements are met
Scrum Project Charter (If needed)
For any new project, if a company requires a charter, then the key elements need to be identified by the Scrum Master, Owner, and Team. The breakdown can be defined as follows: Description (by the Owner), Business Justification (by the Owner), High-level Project Requirements/Epics (by the Owner, team, and Scrum Master), Backlog (if possible, early in this stage, by the Owner, team, and Scrum Master), Risks (by the Owner and Scrum Master), Assumptions (by the Owner and Scrum Master), and Constraints (by the Owner and Scrum Master).
Project Initiation, Epic, and User Story
The process begins with identifying the different areas in the system (Epics) and prioritizing them. This task is done by the Scrum Master, Owner(s), and team. In an ideal Scrum environment, a single role, "Owner," would be designated for this function, but in many companies, multiple owners may be relied upon. For each Epic, a set of user stories is identified and created by the owner(s) and analysts. Each user story follows the standard format: "As a [user], I would like to [perform an action] so that [achieve a goal]." Each user story will be estimated and added to the backlog list, which must be visible to all team members and stakeholders to ensure transparency. Additionally, it is important to identify and clearly define when an item/task is "Done." "Done" is defined differently between companies, and it will become clearer as you read on. In all cases, an item is "Done" when it is "Shippable" or "ready for the live system."
Iteration Initiation
At the start of each "iteration," the Scrum Master schedules a planning session to review each item with the team. The items are selected based on priority and properly ordered within the iteration. The sum of the estimates for the selected items would equal the calculated team capacity, which is always adjusted to account for the points spent on non-project tasks.
Stand-up
Throughout the iteration, there is a daily stand-up meeting. Each person should come prepared to the time-boxed meeting with answers to the following: "What I did yesterday," "What I will do today," and "Obstacles in my way." The Scrum Master's role is to address any obstacles raised and keep velocities updated.
Functional Testing and Demo/Presentation
As a set of items are finished for the owner(s) and pass unit and functional testing, the changes will be presented with the opportunity for adjustments on request. The Scrum Master's responsibility is to negotiate what changes, if any, are possible in the current iteration based on the meeting.
Testing and Definition of "Done"
Some companies define "Done" when the user story has passed both functional testing and the owner presentation. Once all changes for the iteration pass through all testing environments, if the company applies manual or automated regression testing, then some of those companies define an item as "Done" once these tests pass. Many smaller companies would deploy the changes to a live system at this point. Larger companies tend to follow through with user acceptance testing in a pre-production environment. Some companies may define "Done" before UAT and others only after. For smaller companies with a single scrum team involved in UAT, "Done" is defined when the UAT is complete. For larger companies with separate scrum and UAT teams, the scrum team would start a new iteration when "Done."
Regardless of who performs the regression and UAT, any new item or defect discovered after the item(s) are set as "Done" will be placed into the backlog list and re-prioritized accordingly.
Retrospect
At the end of each iteration, a retrospect meeting is held. Each team member should come to the meeting with three topics: "What went well," "What didn't go well," and "How we can improve what didn't go well." This serves as a driver for the Scrum Master to continuously improve the efficiency and quality of the team and system with each iteration.
Copyright © 2024. ADMCAN - All Rights Reserved.
"For every problem, there is a solution"
This website uses cookies. By continuing to use this site, you accept our use of cookies.