Scrum is not just a process which provides a series of sequences that will help you to produce a high-quality product on time and within a budget. Rather, Scrum is a process framework that allows addressing complex problems to deliver products of the highest possible value. At the beginning of 1990, when Scrum was in its infancy, organizations started using the Scrum framework to build the products using various processes and techniques.
Basically, Scrum is an easy, people-centric framework based on the values of:
The Scrum framework consists of the Scrum teams with associated Scrum Roles, Scrum Ceremonies, Scrum Artifacts, and Scrum rules. Each component within a Scrum framework has specific grounds and is a key factor to Scrum’s success, whereas the Scrum rules tie the ceremonies, roles, and artifacts together to govern the relationships between them.
Scrum Framework consists of three Scrum Roles-
The Product Owner (PO) mainly concentrates on maximizing the value of the product and the teamwork. The entire organization respects PO’s decisions. The PO is the only person who manages the Product Backlog. This includes:
The Scrum Master is a Servant leader of the Scrum team. He or she guides the team and the Product Owner ensures that the team members are implementing all the Agile practices properly. The Scrum Master is not only responsible for addressing all the issues encountered in the Agile development process, but also helps the business, product owner, team, and individuals to achieve a target.
The Development team in Scrum is cross-functional, a collection of people who can define, build, and test the required product. The development team size is of 5-9 people and must have all the skills required to produce good quality software. The Development team is a self-organized team that determines the best way to reach out to a solution during product development.
Presenting a list of Scrum rules, that need to be followed within a Scrum framework in software development:
Scrum ceremonies are time-boxed events that create regularity. These are the events that form Scrum.
The Scrum ceremonies are:
Sprint is called the heart of Scrum. Generally, it is of a month’s duration or less, till the potentially shippable product increment is formed. A new Sprint can be started immediately, once the previous Sprint ends.
In this meeting, the objectives of the forthcoming Sprint are defined. This meeting is held towards the start of each Sprint. The Product Owner, Scrum Master, and the team members can be a part of the Sprint Planning meeting.
Daily Scrum is also called the Daily Stand-up meeting. The purpose of the daily Scrum is to know the answers to the three questions about what one did yesterday, is doing today, and what the obstacles are.
This meeting is held once each Sprint is finished. In this meeting, the team demonstrates the work that they have produced during the Sprint. This meeting can be attended by the team members, the Scrum Master, the Product Owner, and the Stakeholder.
This is the last event that wraps up a Sprint cycle. It is held for the teams to share their knowledge earned to enhance the team’s interaction for upcoming Sprint cycles.
The Scrum Artifacts are the objects that are produced as a part of Scrum. The 3 Scrum artifacts are:
Earlier we already mentioned ‘Definition of Done’ and its importance in meeting Sprint goals. Let us now discuss in details.
When a Product Backlog item or an Increment is declared as ‘Done’, every team member should first understand the meaning of ‘Done’ in a Scrum context. This may largely vary from one team to another. But the members ought to have a shared understanding of what it means for a work to be deemed as complete’. This is primarily intended to ensure transparency. This is the definition of ‘Done’ for any Scrum Team and is mainly used to assess when work is complete on the product Increment.
The same definition of ‘Done’ directs the Development Team in understanding how many Product Backlog items can ideally be selected during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that align with the Scrum Team’s current definition of ‘Done’ Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, therefore a Product Owner may prefer immediately releasing it. If the definition of ‘Done’ for a particular increment is a part of the standards or guidelines of the development organization, all the Scrum Teams should mandatorily follow it. If ‘Done’ for an increment is not a convention of the development organization, the Development Team of that Scrum Team must define a definition of 'Done' which is suitable for the product. If there are a number of Scrum Teams working on the system or product release, the Development Teams of all these Scrum Teams should clearly define the definition of ‘Done’ It should be noted that this should be a ‘mutual’ definition.
The increments are cumulative and thoroughly tested, ensuring that all the Increments work together.
Throughout the project, as the Scrum Teams progressively mature, their definitions of 'Done' are expected to expand in order to include more criteria for higher quality. New definitions, as used, may uncover work to be done in previously 'Done' increments. Any one product or system should have a definition of 'Done' that will be considered as a standard for any work done on it.
The team in Scrum is analogous to a boat, always ready to travel in whichever path it is pointed to. The Product Owner is the helmsman, ensuring that the boat is following the correct way, and the Scrum Master is the main repairman, making sure that the team is following all the Scrum ceremonies and getting things done.
Very nicely written!
i want to know more as a scrum master
Why would you justify your phrase " the same holds true for a Scrum Master, who must understand the technical issues the team needs to address and the technologies the team will use to come up with end solutions." using the Scrum Guide? There's nowhere in the Scrum Guide saying that Scrum master must have technical knowledge, so I would like to understand what is the rationale /logic behind this phrase.
Okay thank you so much for the info and you have mentioned in the blog.
I am really happy to read this blog as I was stuck in this type of problem many times and your blog solves my problem in one go. I can't wait to see your next post soon.