Scrum Fundamentals: A Guide to Roles, Artifacts, and Events
Introduction
Scrum is one of the frameworks that's built on the core values of Agile methodology. Scrum is best suited for feature development where a team works on a complex project by breaking it down into smaller chunks (called Stories) in an iterative fashion bounded by time-boxed units (called Sprints) that last two to four weeks.
In this article, we will discuss the roles, artifacts, and events that are common in a typical Scrum team.
Roles
Scrum is used for working on complex projects and hence there is a need for specialization. Typical roles are:
Product Manager
The Product Manager is the representative/voice of the customer for the team. PM provides the requirements in the form of stories. PM maintains a backlog of such stories and keeps them prioritized at all times. This backlog is the source for the stories that the team will work on in a given Sprint.
It is the PM's responsibility to ensure that the product built is valuable to the customer (end-user).
The team doesn't directly report to the PM. So, the PM needs to work with the team by gaining trust and effective communication as an equal instead of a top-down management style.
Scrum Master
The Scrum Master is the one very familiar with the Agile Methodology and acts as a coach to the team in adopting the Agile values and following the Scrum process.
The SM also plays the role of obstacle remover, mainly by facilitating the required people to get together and resolve any issues/obstacles.
Usually (but not always), they go through a formal certification process to ensure that they are familiar with Scrum.
Also, in smaller teams and companies without enough resources, there is no separate SM. Instead, one of the development team members plays the role. This isn't ideal, and we'll discuss the pros and cons of this in a separate article because this is a very common arrangement.
Development Team
Dev, QA, UX, and other specializations needed to build the product form the development team. In modern teams, the engineer is expected to both write the software and the full automated test suite to ensure the requirements are met.
In more legacy product type of companies, there is a separate QA for manual testing and an SDET for automated testing.
The responsibility of the development team is to design, build, test the product, and have a potentially shippable slice of the product that the PM can decide to release at the end of the sprint or later.
Artifacts
Product Backlog
All known work that can be done on the product: new features, enhancements to existing features, and bug fixes are represented in a backlog. The PM will ensure that the backlog is stack ranked in priority.
Sprint Backlog
When a new sprint starts, the team pulls items from the top of the backlog (highest priority) Stories they can work on in a given sprint. How many stories to pull in depends on the estimated story points and typical velocity the team was able to deliver in the past sprints.
Increment
Potentially shippable product that has been worked on in the current sprint. This implies that the code was reviewed, tested, and met the team's definition of done expectations (including updated documentation, etc.)
Events
Also called ceremonies or meetings.
Sprint Planning
Sprint starts with a planning meeting where the team pulls in enough stories from the product backlog. The team commits to completing those stories as a team. This means that they will communicate regularly, ask for, and provide help to each other as needed so that stories are completed on time.
Daily Standup
To achieve team commitment to complete all stories within the sprint, the team meets every workday for a quick meeting to share if they are on track or not and if they need help because they are blocked. This constant communication strengthens team bond and keeps everyone accountable.
Sprint Review/Demo
The sprint ends with a review meeting where the features, bug fixes, and other work done in the sprint are presented to the PM and any stakeholder who joins the meeting.
Sometimes the demo brings up gaps in the product which are then added to the product backlog by the PM.
Sprint Retrospective
Developing software is a challenging task. And we won't get everything right every time. The retrospective is also done at the end of the sprint. The goal is to look back and think of what should we start doing, what should we keep doing, and what should we stop doing?
Action items (if any) are noted and assigned to the appropriate person who can work on them. Progress on these items is reviewed in the next Retrospective meeting.
Conclusion
Scrum provides a logical framework for a team with different skill sets to come together and work on a complex project in a way that allows the team to make incremental improvements and generate a shippable product that the PM and stakeholders can review and iterate in the next Sprint.
It takes time to build a team to work in the Scrum way of doing things. Patience and open communication channels are needed to eventually reap the benefits of this way of doing things.
