Scrum for Non-Engineering Teams: Stealing the Best Bits and Getting Rid of the Rest

At Pusher we’ve discovered that Scrum can be a useful tool for organising non-engineering teams – but not all of it. Here’s how we did it, what we found out and what you can gain from our experiences.

The Growth team comprises mainly of the non-technical functions of the company (marketing, agency support, etc) and it wanted to use the framework as a way of more effectively communicating and collaborating on ongoing projects.

Daily Stand-ups

An early win was establishing daily stand-ups. For the first few attempts we found that it was getting shuffled/missed as people came in late/were away/etc, so we quickly agreed to set a time and stick to it, with a rule that it starts on time no matter who’s there.

At our first retrospective we found that that the set time wasn’t working for everyone, as holding it in the middle of the day was proving too disruptive, so we agreed to move it to 10:30. One of the great things about Scrum is that you can try something differently for one iteration, and, if it doesn’t work, you’ve only lost two weeks.

Another variation is that we often use the instant messenger HipChat for our stand-ups, to include those who occasionally work from home. Although this goes against the concept of this meeting a bit, we find it works because it allows us to continue having daily real-time meetings, while including the maximum number of people.


Another thing that has worked well for the team is the sprint retrospective. We use a fairly simple format of identifying five key questions to base our discussion around, which are:

  • What went well?
  • What could we improve?
  • What didn’t go well?
  • What did we enjoy?
  • What did we learn?

We stick these on a whiteboard and, underneath each one, everyone adds their responses on sticky notes. Once everyone’s done this, we get people to add their ‘+1s’ to any comments they particularly agree with, and discuss these highest-rated comments first.

Making this session an integral part of our iterations has meant we can adapt and change things early on. It’s also allowed us to have open and honest discussions about things that are causing us stress, invaluable at this stage in the process.

User Stories Schmuser Stories

One of the biggest headaches has been trying to define epics and user stories in a way that works for us as a team. A lot of stuff that’s written about this focuses on technical product development, not surprising since it originated in the extreme programming (XP) movement. A quick win was to change the names into something more meaningful – ‘epics’ became ‘projects’ and ‘user stories’ became ‘tasks’.

We tried the ‘as a… I want… so that…’ format, but it didn’t really catch on. We found instead that just writing a short description of the task (e.g. ‘add search function to support documents’) was adequate for our needs.

Sprint Planning Gone Wrong

This is the area where we’ve most felt like we’re trying to fit a square peg into a round hole. In traditional Scrum teams you have a number of cross-functional individuals working towards one product. The Product Owner prioritises the backlog and the team then selects which items it is going to work on for the sprint.

The idea is that, during the sprint, anyone can take any item from the backlog to help achieve the sprint goal (normally some kind of viable working product ready for release).

There are some areas of collaboration in our team, but generally we have individual areas of responsibility working on different projects. Our first attempt at collating and prioritising the entire backlog went disastrously wrong, as we all had our own individual priorities and projects we wanted to focus on and no clear sense of a shared goal.

As a result, we overcommitted on the following sprint, and selected items that generally the team felt were important, but that no one wanted to take on.

Sprint Planning Done Right

After a frank discussion at the retrospective, we discovered that what the team found useful was the communication aspects of sprint planning (being aware of and influencing what other people were planning to work on) but not the collaborative aspect (feeling that everyone had to work together in a way that felt false).

We’ve revised our planning sessions so that each member of the team brings their own items to the meeting (in effect we are all our own Product Owners), which they then present to the group along with their reasons for choosing them. The rest of the team then has the opportunity to ask questions and/or challenge this decision, if they wish.

It may be a move away from one of the original precepts of Scrum as a vessel for ensuring regular delivery of completed work, but making this change has removed an area of stress and enabled us to continue to feel good about using the framework.

Scrumish Scrumban

Going forward, it may make sense for us to move towards a Kanban-type model. Identifying work in progress limits may be a challenge, but an ongoing workflow will be better for the types of projects the team manages. We intend to try out some different methods and techniques over the coming months.

One thing that’s become apparent is that the Scrum process allows for constant review and change – as the Agile Manifesto says, “individuals and interactions over processes and tools” and “responding to change over following a plan”. These are relevant whether you’re a software or non-software team.

Whatever we do, it’s likely to be a combination of methods – we’ve taken the best bits of Scrum and chucked the rest away, to build a process that works for us.

Ready to begin?

Start building your realtime experience today.

From in-app chat to realtime graphs and location tracking, you can rely on Pusher to scale to million of users and trillions of messages