Scrum is probably the most wide-spread Agile framework today. It is considered an upgrade compared to traditional product development practices and is recognized by professionals from various industries all over the globe. Despite the fact the Scrum idea first emerged in 1986, it has gained the greatest popularity in this era of technological revolution.
‘Pure’ scrum or its variants represent about 66% of all Agile frameworks used by companies. Scrum has been successfully tested by numerous projects and teams. For example, universities use Scrum to ensure the delivery of valued projects to customers. Militaries bank on Scrum for ship deployment preparations. The Wikispeed team relies on Scrum to pursue the production of efficient, safe, and fast commuter cars at an affordable price - under $20,000. The most fundamental impact, though, has been on the software development industry.
What is Scrum?
Scrum is a product management framework designed for incremental product development. It’s empirical by nature, empowering teams to hypothesize regarding working patterns, test their ideas, process the experience, and perform necessary adjustments. Scrum is an iterative and flexibly structured PM method, allowing practices from other frameworks where they logically fit.
As much as adopting Scrum requires an assignment of independently functioning team members for prescribed team roles, it’s of crucial importance to have a thorough insight into the Scrum lifecycle.
Since Scrum operates through iterations called Sprints, the main events and artifacts of a Sprint represent the components of a Scrum lifecycle. The Sprint is a timebox lasting up to a month, during which a team is supposed to deliver a specific list of agreed upon items fitting into the confirmed definition of “done.” The duration of a Sprint is fixed. The completed Sprint is followed by the next one with no intermediate periods between.
Parts of Scrum lifecycle
Unlike traditional waterfall methodologies, Scrum does not involve many written reports, and thus, includes only a few artifacts:
- Product Backlog is a written representation of all product features the Product Owner wishes to have in his end product. This is a product specification, broken into separate tickets with either technical details or explicit user stories. The list of requirements is prioritized according to the wishes of the Product Owner. Not all items put into the Product Backlog will be delivered as the list undergoes numerous changes and modifications during the development process. The Product Backlog serves as a wish list, where some wishes are optional and can be changed or deleted.
- Sprint Backlog contains the selection of the Product Backlog items to be delivered within a single Sprint iteration. If the tasks assigned for the Sprint Backlog are delivered, the Sprint Goal is considered reached.
- The increment is a list of Product Backlog items meeting the team’s definition of “done” by the end of each Sprint.
The empirical and flexible nature of Scrum implies a myriad of communications between team members and the Product Owner. The communication is kept in an orderly fashion, with regular prescribed meetings as:
- Sprint Planning is usually conducted in 2 stages. The first stage involves the Product Owner in the discussion of Product Backlog items to be included in the Sprint Backlog. At the second stage, the team discusses the potential ways agreed items will be delivered. Sprint Planning results in the creation of the Sprint Backlog.
- Daily Scrum is a brief morning meeting when the team sets up their tasks for the day. This meeting does not imply any reporting or problem-solving.
- Sprint Review is held at the end of each Sprint and usually involves the participation of the team and the Product Owner. At this meeting, the team demonstrates the increments they’ve achieved and presents them to the project’s stakeholders for further testing and feedback. This feedback is added to the Product Backlog for possible amendments for the next Sprints.
- Sprint Retrospective is a recollection of the whole development process and issues or opportunities which emerge during the Sprint. The Sprint Retrospective results in the addition of items to the next Sprint Backlog.
Roles in Scrum
Although the Development team members are defined depending on the project’s nature and complexity, they are responsible for the agreed increments’ delivery during the Sprint, bringing the expected product value on a timely basis.
Apart from the development team, there are additional constant Scrum roles dictated by the framework rules:
The Product Owner ensures the final product meets the expectations of the stakeholders and is responsible for creating an adequate Product Backlog and guiding the team in the right direction throughout the development course. The Product Owner is supposed to take an active part in Sprint Plannings and Sprint Reviews. He addresses cases of conflicting development directions within a team and those opposed to the initial Project’s course.
The Scrum Master is responsible for compliance with Scrum values and principles and for ensuring the initially agreed upon development practices and processes are in compliance. The role does not provide any real authority, but the person holding this position should be able to encourage the team to make its involvement count.
How does Scrum work?
Working within the Scrum framework means sticking to its central principles of transparency, inspection, and adaptation.
Transparency means every team member is aware of issues the other team members face which threaten the delivery of the expected increment at the end of Sprint. Scrum is often practiced in open space environments, adding to the transparency of the development process.
The inspection principle regards the process of regular reflections during the development process to detect possible problems at early stages, provide timely advice on Product Backlog items’ modifications, and refine the overall process of items’ delivery.
Adaptation is the result of these modifications to improve the initial requirements corresponding to the actual technical possibilities.
When we should use Scrum?
Scrum is best used for projects that do not involve exhausting documentation and are flexible in intermediary requirements as long as the final goal is reached. Flexibility is necessary in terms of a project’s timeframes and the budget involved. Scrum lends itself best to small-sized teams of up to 7 people, but this limitat is negotiable.
Some think too much flexibility and lack of comprehensive documentation on every deliverable is a drawback. However, considering the level of transparency and the unstoppable learning process within the development cycle it involves, the smallest possible outcome becomes a significant cost-effective result of the framework, not to mention flawless product quality and refined product characteristics. Besides, it can’t be said the lack of written reporting harbors any hidden risks to the level of stakeholders’ awareness regarding product development.
The essence of Scrum eliminates the involvement of unqualified staff and invites only responsible employees with solid field background. Regular meetings serve as a detector of probable issues and technical inconsistencies and settle them at the earliest convenience.