In the previous article, we have already known about Agile. Today will tell you about Scrum.
What is Scrum?
Scrum is an Agile-based software development process, so it follows Agile Manifesto’s principles.
What does the Scrum framework have?
To use Scrum, we need to comprehend and apply the elements that create Scrum, including core values (also known as the “three pillars,” or the three pillars of Scrum), roles, events, and artifacts specific to Scrum.
Scrum’s three pillars (or core values)
To be successful with Scrum, information related to development must be transparent.
Information can be a product’s vision, customers’ requirements, work progress, problems, barriers, etc.
So people with different roles can have enough information to make valuable decisions to increase work efficiency.
Scrum tools and events ensure transparent information to all parties.
Constant inspecting Scrum’s activities ensure problems and solutions are uncovered so that useful and diverse information reaches project stakeholders. Continuous and thorough scrutiny is the starting mechanism for continual adaptation and improvement in Scrum.
Scrum is flexible like other Agile methods, so it’s highly adaptable. Based on transparent information from inspection and working processes, Scrum can positively respond to change, leading to project success.
In Scrum, the teams involved in software development is divided into three purposes with a clear responsibility to ensure the optimization of specific tasks as follows:
1. Product Owner
Who is responsible for the project’s success, which defines the requirements and ultimately evaluates the software developer‘s output.
2. Scrum Master
Who fathoms about Scrum and ensures teams can work effectively.
3. Development Team
A self-managed cross-functional group that transforms the requirements organized in the Product Backlog into system functions.
Scrum defines rules for four primary events to build an environment and code of conduct and cooperation for project members.
Sprint is an iterative segment of the software development process, often with a short time frame (1-4 weeks).
1. Sprint Planning
Development teams meet Product Owners to make plans for a Sprint. The schedule includes requirement selection that needs to develop, analyze and identify tasks and estimates of the time required to complete tasks.
Scrum uses a gradual and incremental schedule, so planning does not happen once in a project’s life cycle. Still, it is repeated repeatedly, adapting to the actual situation in the process to the product.
2. Daily Scrum
Scrum Masters organize meetings for Development teams every day within 15 minutes to share the work process and the challenges during a Sprint development process.
3. Sprint Review
At the end of Sprint, development teams with Product Owners will review those completed works (DONE) in the Sprint and suggest any necessary modifications or changes to the product.
4. Sprint Retrospective
Under the help of Scrum Master, development teams will review through finished Sprint and find ways to improve the workflow and the product itself.
Uses simple but useful tools to work.
This is a prioritized list of the project’s other features or outputs. It can be understood as a project’s requirement lists.
The Product Owner is responsible for prioritizing each Product Backlog Item in the Product Backlog based on values defined by the Product Owner (usually the business value).
This is a plan for a Sprint and the result of Sprint Planning.
With the Product Owner’s combination, teams will analyze the requirements from high to low priority to realize items in the Product Backlog as a TODO list.
This is the chart to show the project’s trend based on the necessary amount of time it takes to complete the work.
Burndown Chart can be used to track the Sprint process (called Sprint Burndown Chart) or the whole project (Project Burndown Chart).
According to the new definition, the Burndown chart isn’t Scrum’s standard element but still is used widely due to its usefulness.
How does the Scrum process work?
- Product Owner creating Product Backlog holds projects’ requirements with items sorted in order of preference.
- The development team realizes the Project Owner’s requirements by repeating sprints from 1 to 4 working weeks (called Sprint). The input is the items in the Product Backlog. The output is the complete package that can be delivered (Potentially Shippable Product Increment).
- Before the team runs the sprint, the development team will meet the Product Owner to make each Sprint plan. The meeting (as a Scrum approach) is Sprint Backlog that contains the work to be done during a Sprint.
- During the development process, the team needs to update Sprint Backlog and perform the Daily Scrum to share the working process and the active process’s challenges. The team is empowered to self-manage and organize tasks to complete in the Sprint.
- At the end of Sprint, the team will create fully functional software packages shippable to the customer. Sprint Review meeting at the end of the Sprint will help the client see what the team has delivered, what has to be done, or what has to be changed or improved.
- After the end of Sprint evaluation, Scrum Master and the team hold a Sprint Retrospective meeting to look for improvements before the next Sprint starts, which will help the section continually learn and mature through each Sprint.
Sprints will be repeated until items in the Product Backlog are completed or when the Product Owner decides to stop the project based on actual circumstances.
Using the tactic of “done something more value first,” the items that bring more value to the project owner are always completed first. Therefore Scrum still gets the highest importance to the project investor. Because processes are continuously improving, the team is often very productive. These are the two great benefits that can bring to an organization.