Scrum as an Agile framework is currently most popular in IT development teams. However, that does not mean that it cannot be effectively used in other domains. In fact, as an Agile framework for managing projects, it can be used wherever people work on projects on a regular basis. It can be used in a particular division of a company – like new product development in an automobile company, and can also be used in a particular function of a company – like marketing. This article will highlight how the Scrum framework can be used very effectively to manage marketing projects.
Marketing as a function revolves around projects. Marketing professionals work on a variety of projects – ad campaigns, email campaigns, product prototyping, market research etc. More time is spent on projects rather than operational activities. Hence, Scrum can be especially beneficial for marketing teams.
Let’s say the marketing team is tasked with the project of launching a new car model. How can it use Scrum? Well, it actually is quite simple (one of the basic objectives of Scrum – to keep it simple). You start off with stating the project vision – launching the car in a defined area, say, the state of California. Then you need someone to spearhead the whole project – the Product Owner. He/she will decide who all will be part of the Scrum team. These are the people who will actually be doing the various tasks in the project and not the ones who simply have an interest in the it.
So now you have the people who will be working on the Scrum project. What next? The team needs to understand the customer requirements. These are defined in the form of User Stories. In our case, two of the user stories might be “I need to test drive the car before I buy it” and “I need to know all its performance specifications.”
The User Stories are approved and entered into what is called the Prioritized Product Backlog. This is the master document which guides the team in the project. It contains the User Stories, and from it the Scrum Team derives the tasks which are required to fulfill the requirements for each of the user stories. So in our example, the first User Story about test drives might include tasks like “Decide number and models of test cars needed,” “Brand the test cars,” “Create a test-drive feedback form,” “Decide on the tasks to be performed by the salesperson before the test drive” etc. The PO and required stakeholders then decide on a Release Planning Schedule which lays out the schedule of shipping out completed deliverables to the customers. The team then estimates the time required for the various tasks. Based on the above, the Scrum Team selects and commits to tasks to be included in the first round – called Sprint. A Sprint duration can vary from one to a six weeks, with four weeks being the most common.
The team then works on completing the tasks in a particular Sprint. To ensure that things are on track, the Scrum team has a Daily Standup Meeting which is time-boxed to 15 minutes in which all the members stand together and discuss the status of the different tasks. Tasks are often written on post-it notes and stuck on to a whiteboard with 3 columns – “To be done,” “In Process” and “Completed.” The team then works on the tasks from the first column to the third column. At the end of a Sprint, when the team has hopefully completed all the tasks, a Sprint Review Meeting takes place where the team discusses what went right and what provides improvement opportunities. At designated points in time, as laid out in the Release Planning Schedule, the team ships out completed deliverables.
This process continues until all the deliverables and tasks are completed in the Scrum project. The high level of involvement and communication involved in the Daily Standup Meetings is the key to an effective implementation of Scrum. Thus, by following the above process, marketing teams can ensure speedy completion of projects with high quality outputs without getting bogged down by a lot of documentation and processes.
Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOK GuideTM)
