Agile for non-tech teams: 8 things you need to know

What is Agile?

It’s 1986. The retrofuturistic 80s are in their full glory. The USA and the Soviet Union are caught up in the space race, teens falling in love with Marty McFly and Doc’s Delorean, Chernobyl explodes into a catastrophic nuclear disaster, and Oprah first airs nationwide. All of these events had a dramatic influence on the way we and our culture is today.

But there was another important event, which at that time went unnoticed. Something that has changed the way 90% of the tech teams manages their workflows, and become more productive. The almighty SCRUM was born.

First introduced by Hirotaka Takeuchi and Inkujiro Nonaka in their HBR article The New New Product Development Game, Scrum was later heavily embraced and influenced by Jeff Sutherland, who’s probably done the most to popularize and educate the crowd about Agile methodologies. 

Jeff’s book SCRUM: The Art of Doing Twice the Work in Half the Time became the handbook for anyone who’s trying to get their team into the agile routine. And we can’t resist from strongly recommending it for starting off. Regardless whether you need SCRUM for non-IT projects, for tech teams, or whatsoever, the book will come in handy for sure. 

But do agile methodologies work only for the developers? Or are there any non-IT applications for SCRUM? Can you make the most out of these management techniques for your non-tech teams as well?

I won’t hold the intrigue: Agile is golden for managing marketing, operations and sales teams. We’ve proved it through our own experience and decided to write about it for the sake of anyone who still hasn’t jumped on board of the magical train.

Getting started with Scrum

what is scrum

At we deal with developers all the time. We’re a marketplace for hiring vetted developers, after all! So, naturally, trying to find the best ways to manage the workflows and improve the customer experience, we’ve learned about Agile.

At first, we started following the framework for everything connected to development and managing freelancers’ projects. Not too long after that, we saw the benefits we couldn’t ignore.

And being a startup, we just couldn’t afford not trying to get the same results for the rest of our team.

Getting into any new routine is quite difficult. Especially, when you need to learn a lot of things you’ve never heard before. With Scrum, it can get extra complicated and confusing since you’ll have to decide which exactly things you should care about and which are irrelevant to your marketing team.

Having made our mistakes in SCRUM management for non-IT team, we decided to share our list of 8 things you need to know about Agile for starting a marketing Scrum team. These are the 8 things that worked for us the best, the only ones we’ve decided to keep doing. We’ve tried doing some more advanced techniques, but it turned out that they only make the framework more perplexing, and there are no additional advantages to those.

Think of it as of your mini “SCRUM for non-technical teams” training course. 

8 steps to a non-tech Scrum team

1. Sprints

Sprints are the short iterations for working on a list of tasks, which last the same specific amount of time.

In our case, every sprint lasts a week. For the majority of non-tech teams week is the best period to settle with for sprints, though some people prefer longer periods up to a month. We felt like sticking to 1-week sprints because we felt they help be the most productive. But feel free to experiment and choose what’s right for you.

Another tip is to start sprints on Tuesday. That way, you still have the entire most stressful day of the week, aka Monday, to round up all the stuff you’ve been working on past week and prepare for the weekly planning.

2. Sprint planning

When planning the next sprint, always remember to include only those tasks that can be completed within a week, or whatever long your sprint is.

If you need to work on some bigger project that requires more time, divide it into smaller bits.

Always include more tasks than you feel you can physically get done. This strategy will not only help you get more productive but also will set your planning game on point.

The best practice is to plan 30% more tasks than you’ve managed to close last week. For keeping track on how much we’ve done in a sprint, we use story points.

3. Story points

Story points are used for task estimation. It’s an intuitive way to rate any task based on how difficult and time-consuming it is.

There are many different techniques used in Agile teams for estimation, but the one we decided to stick to is the story point system that replicates the Fibonacci sequence:

1 2 3 5 8 13 21 34 55 89

fibonacci scrum

This sequence is usually used instead of linear 1 to 10 because it makes estimations easier for the human brain.

Some tasks will be harder to estimate correctly from the first time, and you’ll find yourself adjusting your initial guesses. That’s alright! Because, after all, most people’s tasks are usually repeating, so gradually you will set them up with some standard story points. Like, in my case, I’ve settled with 89 points for any long read I do and 8 points for any Quora answer I write.

One thing we never do inside our team is comparing story points between employees or whole departments. The important thing to understand is that Scrum and Agile methodologies are not used for choosing winners in any weird productivity races, and the only person you should be competing with on this matter is yourself.

The main point of Scrum is to reach your full productivity potential. And as long as you feel there is still room to grow, I strongly recommend you to keep score of your story points.

We kept ours in a basic Google sheet for the first few weeks until we felt comfortable saying that we’ve optimized the workflow to the point we couldn’t do any more tasks done in a sprint. And we suggest you do the same. Here’s what the table looked like:

story points for productivity

As we’ve mentioned before, it’s best to plan 30% more tasks than you actually did the previous sprint.

And here’s how to tell how good is your planning:

<70% – either over-planned or unproductive week

70-100% – just perfect!

100% – almost always sign of bad planning

4. Acceptance criteria

Story points can be assigned only for the 100% closed tasks.

But how do you know the task is completed? One thing when you get a task to write the text for a new email template, and it’s self-explanatory: the acceptance criterium is «written text».

But what if you take a project like creating a new landing page? Is it done when you are all set with copy and design or do you need to make sure it’s released and ready to go for your next marketing campaign? That’s when acceptance criteria come into play!

5. Retrospective

retrospective in agile

Sprints retrospective, in our case, basically, means a weekly meeting held between the marketing team and founders where we discuss what has been done during the last sprint.

If we feel we could have done better, we try to figure out what exactly happened that didn’t allow us to show the full glory, and how to fix it.

The main point of such meeting is to distinguish what blocked our progress and eliminate that factor. Once we do that, it’s important to see if the result of such elimination turned out to be what we expected it to be or not.

Best time to go through the retrospective is right before planning, since the discussion may actually affect the planning itself.

6. Kanban

Kanban board protects your team from nervous breakdowns and overloads.

It’s a tool that allows to visualize your team’s workflow and set up the safety switches. Here’s how the classical minimum-requirements-kanban-board looks like:

kanban board marketing

But we found them to be not so convenient, so we’ve customized the columns according to the workflow we have:

non tech kanban board

Backlog the place for all the ideas and things you’d like to work on in future. You don’t have to filter or prioritize the cards that go on this list. Backlog should be revised before every sprint planning, and we can grab any task we feel belongs on your to-do list for this sprint.

Chosen to work on everything you want to work on during the sprint belongs here. A great tip is to check up with any teams that might need help from you. That will allow you to get rid of any unexpected tasks that are to be avoided in agile.

In progress the In Progress list can’t include more than 2 tasks per person at the same time. This is done to make sure your coworkers can focus on only one thing without jumping from task to task. This is the safety switch that ensures the maker’s schedule.

Review the list for all the tasks that have been done on the maker’s side but are awaiting any sort of reaction or approval from someone else.

Release all the tasks completed during the current sprint. We separate them from the rest of the tasks because it makes easier to go through the retrospectives and to count the story points.

Done all the tasks that have been 100% done in any past sprint.

7. Daily standups

scrum stand ups

Daily standups are the opportunity to sync with the whole team. Since we have a distributed team, we started off with daily Hangouts video-calls. But we quickly noticed, that those were taking too much time and required some team members to go out of their routines ruining the whole idea of the flexible schedule we have.

So, we switched to writing the daily updates in a dedicated Slack channel.

There are three crucial things everyone has to post every day:

  1. What tasks you’ve completed yesterday
  2. What you’re going to work on today
  3. What obstacles you have that get in your way on completing any of the tasks and how the team can help you with those

8. Management tools

There are tons of management tools that support Scrum, Kanban and all the rest of your agile team’s needs. We’ve already covered some of them in our earlier article on How to Manage Remote Teams.

What we’ve discovered through experimenting, is that while most of the tech teams prefer Atlassian’s Jira for agile task management, it turned out to be too complicated for our small non-tech team and preferred the free version of Trello along with the Agile tools extension.

But no matter which management tool you decide to stick with, here are a few tips that will make your team collaboration most effective:

Clear task naming

Try to choose short, but self-explanatory task names.

trello agile board

Choose labels.

Labels make it easier to navigate and prioritize the tasks, especially if your kanban is a team board.

Choose labels

Assign the executor.

You need to know who’s responsible for the project. It also helps to distinguish the personal workloads.

Assign the executor

Describe task.

If you are assigning the tasks for anyone else, add the task description that clearly states what needs to be done. Attach any files or links your team-mate might need to complete the task.

Task description

Ask for review.

Any time you’re done with the task, but still need someone to review it or do anything else with it, before you can complete it, ask them for a review in a comment to the task. Tag them in a comment, add a specific call to action, and provide with all needed materials.

Review process


Implementing the elements of Agile, Scrum and Kanban for marketing teams is a great first step, no matter what they are working on.

These techniques help to visualize the workflow, keep better track on personal and team efficiency, provide feedback when it’s needed and change faulty processes that slow you down. If you need a system that is designed to help your business grow fast, give it a go.

From a perspective of a non-tech team that has implemented elements of Agile team management into our daily routine, our biggest advise is to research the basics, experiment and come up with the framework that suits your specific needs, instead of stressing out in attempts to follow the guidelines that are not applicable.