As another way to keep discussions of agile marketing grounded in the reality of daily marketing business, we’ve compiled this list of common terms and their definitions (as they apply to agile marketing).
UPDATE 8-12-15: We’ve added some additional terms referring to Kanban and Scrumban methodologies as well as other terms we’ve had questions about.
See one that we missed? Drop us a note in the comments and we’ll add it to the list!
Adaptability: the ability of a marketing team to pivot or adjust to changes in the market, feedback from their customers, the competitive landscape, and data from their own campaigns. The goal of adaptability is to avoid being trapped in a pre-established marketing plan even when it becomes clear that changes need to be made. A primary benefit of agile methodologies.
Backlog: a list of user stories or projects that have not yet been worked on. See also “Sprint backlog” and “Product backlog.”
Burndown chart: A visual chart showing daily progress of tasks during a sprint
Business owners: A small group of stakeholders that has ultimate responsibility for the value delivered by a sprint. Their primary role is in sprint planning and review to help with prioritization.
Chickens v. Pigs: Based on the joke that if a pig and a chicken were to open a restaurant together the pig would be committed, but the chicken would only be involved, this distinction refers to people who are directly responsible for completing stories within a sprint as opposed to those who observe but don’t contribute directly.
“Done”: Generally used in Scrum only. The team and product owner must determine what criteria need to be met in order for each project to be accepted as complete. These criteria are likely to change from sprint to sprint and project to project, but must be made explicit for all team members and stakeholders. Stories that don’t hit all these requirements won’t be considered “done” at the end of a sprint.
Epic: An extremely large user story, goal or objective that needs to be tackled over multiple sprints and/or broken down into smaller, more manageable increments.
Failing Fast: The idea that failure isn’t a negative outcome, it simply reveals a course of action that wasn’t optimal. Because most agile teams can roll out an experiment, evaluate the results, and react almost immediately, a “failure” is more like a lesson.
Fans: Other employees that, while not players in the sprint, may have projects that are impacted by sprint objectives. They typically observe and do not participate in sprint planning or review. Sometimes referred to as “chickens.”
Hypothesis: A possible source for a sprint task/objective, this is something your team wants to test and evaluate. E.g. By moving our introductory video so that it’s adjacent to our call to action we can improve the both video views and action completion rates.
Iteration: A repeating instance or occurrence. Sprints are said to be iterative because they are repeated over and over with new tasks/goals/objectives. Waterfall marketing plans are not iterative because they are done only once.
Kaizen: Used in Kanban or Scrumban only, a Kaizen can take place at a pre-determined interval (e.g. after so many blog posts) and/or when a team member feels the need to examine some part of the agile process. It essentially translates to “continuous improvement,” or “change for the better.”
Players: Those taking part in a sprint by owning particular tasks. Also known as “Pigs.”
Product Backlog: A prioritized list of high level requirements for the product
Product Owner: In Scrum, the person in charge of managing the product backlog by ensuring it’s accurately prioritized, reviewing the team members’ work, and otherwise working closely with the Scrum team to make sure the product is being best served by their efforts. The product owner can set tasks to be done, but the team choose how best to accomplish those tasks.
Push-based v. Pull-based Systems: In a pull-based system, team members will grab items from a prioritized backlog as they finish their current tasks. A push-based system will distributed the most important items from the backlog at a set time (typically the beginning of a sprint.)
Scrumban: A hybrid of the Scrum and Kanban methodologies, Scrumban is typically a good option for Scrum teams who are looking to move past the need for ceremonial meetings. It can also be a better option for teams who are not co-located. It relies on a visible, shared board to track tasks, Work In Progress (WIP) limits, and the Kaizen review process.
Scrum or stand up: A daily meeting during which players literally stand up and report to one another on what they did yesterday, what they plan to do today, and any obstacles they are encountering.
Scrum master: The person responsible for running all sprint plannings, sprint reviews, sprint retrospectives and daily scrum meetings. Basically ensures that things stay on task during these meetings. Also responsible for helping remove impediments to progress brought up during daily scrum/stand ups.
Sprint: The length of time allotted for achieving particular marketing goals. Software development sprints tend to run about 2 weeks; marketing sprints may need to be longer if statistically relevant data on current objectives will take longer to gather. Feel free to adjust the length of your marketing sprints based on what you’re trying to test/achieve for that particular sprint, but don’t go any longer than six weeks.
Sprint Backlog: A prioritized list of tasks to be accomplished during the sprint
Sprint planning meeting: A meeting held at the beginning of a sprint. Attended by players, business owners, scrum master and fans. During this meeting you should determine what you want to achieve during the sprint using the product backlog and dialog with the entire team to determine the time that work will take. This will form the sprint backlog.
Sprint poker or planning poker: How the team estimates the relative effort required for addressing user stories in the backlog. It’s called “poker” because it is often done with playing cards. As each story/task comes up, players put cards face down in front of them to indicate their “vote” for how long it will take. Then everyone turns their cards over and comes to a consensus based on the results.
Sprint retrospective: A meeting that happens at the end of a sprint to determine not whether tasks were completed but how the sprint as a whole went. Basically sets out to determine what went well and what could be improved for the next sprint. Typically attended by only the players and scrum master, though business owners may sometimes join.
Sprint review: Business owners, players, scrum master and fans re-assemble just as in the sprint planning meeting, this time to see what goals were completed and which ones were not. Players get to show off what they have completed and/or learned, such as new email campaigns, blog posts, or metrics. Incomplete goals may be moved into the product backlog for consideration in future sprints.
Success criteria: Criteria used to determine if a task is complete. Typically evaluated by a product owner. See also “Done.”
Swarm: When tasks reach their WIP limit, a sprint is in danger of failing, or some other high-priority situation arises, agile team members may swarm a user story or task to get it done as quickly as possible. This typically works best in highly cross-functional teams that have similar skill sets.
Timebox: A predetermined amount of time during which a set number of tasks will be completed. This can refer to the time allotted for a full sprint (typically measured in weeks) or for a meeting (hopefully measured in minutes).
User story: A sentence that states in plain language what a customer or consumer may want or need from your product. They are used to drive what goals and tasks are addressed during a sprint based on their priorities. Example: As a digital marketer, I want to download a daily schedule so I can more effectively prioritize my tasks. To address this user story we might create a daily digital marketing schedule template and then place it, with appropriate calls to action, around our website and other channels (and then track results of course).
Work in Progress (WIP) Limits: Typically used only in Kanban or Scrumban, WIP limits refer to a fixed number of cards/tasks that may be in a category at any one time. Your team may only be able to handle having four tasks in your “doing” column; before you can add another, one of those must be moved into the “completed” column. When a WIP limit is exceeded a team may swarm a card to get it moved to the next point in the process and make room for the next one.