Scrum is an agile methodology that can be applied to nearly any project; however, the Scrum methodology is most commonly used in software development. The Scrum process is suited for projects with rapidly changing or highly emergent requirements. Scrum software development progresses via a series of iterations called sprints, which last from one to four weeks. The Scrum model suggests each sprint begins with a brief planning meeting and concludes with a review.
The Scrum model suggests that your projects progress in a series of sprints. In keeping with an agile methodology, sprints are timeboxed to no more than a month long, most commonly a week or two.
Scrum methodology advocates a planning meeting at the start of the sprint, where team members determine how many items they can commit to, and then create a sprint backlog, which is a list of the tasks to perform during the sprint.
During an agile Scrum sprint, the Scrum team takes a small set of features from idea to developed and tested functionality. At the end of the sprint, these features are done, meaning coded, tested and integrated into the evolving product or system.
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than 15 minutes. During that time, team members share what they worked on the prior day, will work on that day, and identify any impediments to progress.
The Scrum model sees daily scrums as a way to synchronize the work of team members as they discuss the work of the sprint.
At the end of a sprint, the team conducts a sprint review during which the team demonstrates the new functionality to the Product Owner or any other stakeholder who wishes to provide feedback that could influence the next sprint.
This feedback loop within Scrum software development may result in changes to the freshly delivered functionality, but it may just as likely result in revising or adding items to the product backlog.
The primary artifact in Scrum development is, of course, the product itself. The Scrum model expects the team to bring the product or system to a potentially shippable state at the end of each Scrum sprint.
The product backlog is another artifact of Scrum. This is the complete list of the functionality that remains to be added to the product. The product owner prioritizes the backlog so the team always works on the most valuable features first.
The most popular and successful way to create a product backlog using Scrum methodology is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer.
The sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality it committed to deliver during the sprint.
Additional artifacts resulting from the Scrum agile methodology is the sprint burndown chart and release burndown chart. Burndown charts show the amount of work remaining either in a sprint or a release, and are an effective tool in Scrum software development to determine whether a sprint or release is on schedule to have all planned work finished by the desired date.
Even if you are new to Scrum, you may have heard of a role called the ScrumMaster. The ScrumMaster is the team’s coach, and helps Scrum practitioners achieve their highest level of performance.
In the Scrum process, a ScrumMaster differs from a traditional project manager in many ways, including that this role does not provide day-to-day direction to the team and does not assign tasks to individuals. A good ScrumMaster shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.
While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team to the right goal. The product owner does this by creating a compelling vision of the product, and then conveying that vision to the team through the product backlog.
The third and final role in Scrum project management is the Scrum team itself. Although individuals may join the team with various job titles, in Scrum, those titles are insignificant. Scrum methodology states that each person contributes in whatever way they can to complete the work of each sprint.
This does not mean that a tester will be expected to re-architect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked before adopting the agile Scrum model. But with Scrum, individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team.
One way to think of the interlocking nature of these three roles in this agile methodology is as a racecar.
The Scrum team is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. And the ScrumMaster is the chief mechanic, keeping the car well tuned and performing at its best.