Scrum is an agile framework for team-based, complex problem-solving. Scrum is a great fit for designed for CRM customers and partners that want an agile process, faster releases, improved collaboration, greater transparency, and reduced risk compared to a traditional, sequential CRM project.
This post is the first in a series aimed at CRM customers and consultants who want to learn how to use Scrum in a CRM project. In this article, we'll learn the basics of the Scrum framework with an introduction to its pillars and principles, roles, events and practices.
Core pillars and principles
Scrum has three pillars: transparency, inspection and adaptation.
- Transparency. Our requirements, progress, and issues are all out in the open.
- Inspection. We frequently inspect what we've built and how we built it.
- Adaptation. We frequently adapt what we're about to build and how we'll build it.
Scrum also embraces the core principles of commitment, courage, focus, openness and respect.
- Commitment. The CRM team commits to achieving the customer's goals.
- Courage. We have the courage to solve tough problems.
- Focus. We focus on the work of the CRM project.
- Openness. Our communication is open and honest.
- Respect. The team members respect one another's professionalism and ability.
Embracing these values is more important than perfectly adopting any of the practices.
In Scrum, a self-organising team develops working software in a two-week iteration called a sprint.
The product owner provides the vision for the CRM system, decides on the release dates, describes and prioritises the requirements, and accepts completed work as done. The team agrees on the definition of done as the project starts. The development team is a cross-functional, self-organizing group of up to nine members. Working on the highest priority items, the CRM team analyses, designs, develops and tests some items in each sprint. A scrum master guides the team and removes any impediments they encounter.
We run a release planning workshop at the start of each release to determine the major goals for the release. The story mapping practice provides a shared understanding of the desired business outcomes, user roles, epics and releases.
At the start of each sprint is the sprint planning workshop to discuss and commit to the items for the current sprint.
During the sprint, the team holds a daily scrum meeting each day to check-in on each others' progress. Story previews provide the product owner with an opportunity to provide feedback on features mid-sprint before they are done.
A periodic storytime workshop reviews items in the backlog for future sprints. Once items meet our definition of ready, we play a game of planning poker to estimate their complexity using relative point estimation.
The team demonstrates the completed items to the project's stakeholders in the sprint review meeting at the end of each sprint. Then they hold a sprint retrospective workshop to reflect on their work.
The product backlog represents all the required work, known as product backlog items. A product backlog item can be a feature, bug, chore or spike. We use a user story to describe each feature and its acceptance criteria. We split large stories into smaller ones that we can deliver within one sprint as we being to work on them.
The sprint goal describes the team’s focus during the sprint. The sprint backlog represents the tasks the team needs to complete to complete the stories and reach the goal. The sprint board displays the CRM team's progress with the stories' tasks and gets updated daily. The sprint burndown chart tracks our progress during the sprint. Velocity is the amount of work completed in each sprint and gets tracked in a release burndown chart. Documentation produced during the sprint includes the system design statement, test cases, and user guide.
The development team use can pair programming to provide collective ownership of the features they develop. Automated releases combine continuous integration, automated deployments, and automated testing to ensure that completed features are released frequently into test environments for continuous acceptance testing by the customer.
Putting it all together
Scrum is a framework. It's not a prescriptive methodology, so other agile practices can be combined with it.