How we use Scrum: Agile in a content strategy context

Scrum sounds like something people do in the mud, if you’re not across agile frameworks. But agile is the buzzword of the hour. In this article, you will find out how we’ve modified scrum so that it works inside a content strategy company. It works whether you’re a solo practitioner or in a team.

Why scrum, specifically?

We love scrum because it’s a complete process. It has a start and a finish point. It puts boundaries on your time, which helps you to focus your activity. And it pretty literally grabs you by the scruff of the neck and marches you forwards.

And while there’s some debate about how to estimate your jobs in scrum (effort versus time), that least there’s even a consideration about the difference.

If you’re used to using kanbans (like, say, Trello), you know the power of pushing jobs through a series from ‘to do’ to ‘done’. It gives you the ability to get a clear picture of what’s in front of you, where everything is at, what you need to follow up, and how long your backlog (the to do part) has been sitting around. While powerful it doesn’t do things like help your continuous improvement, improve productivity, work on your culture, or any of those awesome things. Scrum does.

In the Pixie Scrum, our customers are our product masters… sort of

In Plain English, this means that our customers have full control over what jobs are done in which order, in a given a timeframe. And they also have the opportunity to decide whether or not to exercise that control, week to week. This means that, rather than you paying us to do a job and simply trusting that we’ll do the Expert Thing and get it all right, suddenly you’re involved in the process. We will put forward our best thinking around priority, deliverables, and etc, but before we do it, you get notified. You get asked whether it’s right, you have the ability to move things around (or replace them entirely).

The upshot of being the product master is that you know exactly what we’re going to do for you in a given timeframe, and in what order. And the upshot for us is that it’s always 100% clear about what we are capable of doing for our customers in a given week. Any extra requests are evaluated in light of the entire schedule. And if they’re super urgent, then the customer is asked what items that thing needs to replace.

If you have an urgent fix, we ask you what job you want it to replace or delay. Each week only has a finite capacity, and as much as we like to work magic, sometimes there are limits.

This is why we send customers The Plan for the Week. That email (which every client gets) puts our most important people (them) in the most important seat (in charge of their work).

Organising work focuses on client value

When we do our work, what order do we do it in? In the order of client value. And then, according to the product of collaboration with clients. But on a daily, team-​based level, how does this work? The way it needs to work to get it done in the best way possible.

We ask ourselves the question: “What could I do now right now to move this client’s job forwards?” It’s an empowering question, and it works whether you have 5 minutes between meetings, or 3 hours just to buckle down and get stuff done.

And ultimately, the small jobs — the ones that take hardly any effort — are smashed out of the way quickly. Jobs that take more effort are slotted into times where focus is at its peak. And somehow it all works.

Then, if there are problems with this approach, we deal with it during our ‘clean code’ process so that we don’t face this problem next week.

Daily scrum, clean code, sprints, sprint reviews… er, wut?

Ok, so if you know anything about scrum, then you know that there are things called Daily Scrum, Clean Code, and Sprints. Here’s our interpretation of these things at Brutal Pixie:

  • Daily scrum: A maximum fifteen-​minute evaluation of what we achieved yesterday, what’s blocking work, how we will deliver value today.
  • Clean code:  A daily process of getting back to Inbox Zero, updating client files, checking burndowns and keeping notes for what to adjust tomorrow.
  • Sprints: A specific period of time. In our case, sprints are one week long. They start on Monday and end on Friday.
  • Sprint Review: In scrum, a sprint review is demonstrating achievement so far for customers. But in our case, it’s an email. The things that are done and releasable are the things that we achieved during the week. Hence, every client gets the Update on Fridays. The Update says, hey, this was what we were working on for you on Monday (remember that?), and here’s what was achieved. It also says, here’s what we’re waiting for from you (if anything); and, here are all the things.

Giving our clients visibility is paramount. There is nothing worse than paying a service provider, then chewing your fingernails wondering what the hell they’re doing for four (or six or eight weeks). When that happens, you send anxious emails, people get annoyed, and the whole experience is, well, awful. At best, it’s sub-​optimal. Book-​ending our sprints with the Plan and the Update helps our clients to feel in control.

But the other clever thing? It keeps us focused, internally. It says: Here’s what we promised. And then at the end of the week: Here are all the promises we kept. Additional things are sent through on Fridays too. Where were we able to over-​deliver to make your life better? That’s all in there, it’s all visible, everyone is happy.

This image depicts the six scrum principles in a circle: empirical process control; self-organisation; collaboration; value-based prioritisation; time-boxing; iterative development. The image is from the website Scrum Study.
Source: Scrum Study

The sprint retrospective

Every business should have a weekly retrospective, to keep improving and being awesome. And every individual should have a personal retrospective too — otherwise you’ll never keep on your goals pathway. So for us, sprint retrospectives are meditation time, the time where we look at the business, the time to evaluate what’s working … or not.

The sprint retrospective asks:

  • What worked?
  • What didn’t work?
  • What challenges did we face and why?
  • What can we do to be happier in our work?
  • What can we do to be more productive in our work?
  • What can we do to lift quality just another touch?

Then at the conclusion of the retrospective, we dive immediately into planning the next sprint, getting the client communications in order, and generally making sure that we can hit the ground running on Monday morning. If any ideas get traction in the retrospective, we put those into the next sprint too.

User stories, tasks, bugs, epics… all the daily stuff

At Brutal Pixie, we write user stories for everything that needs to be done. And “done” is considered “done done”: All the things to achieve a goal that a client is expecting to see finished. Those ‘things’ are tasks.

If problems come through to us, we add them as bugs and prioritise them accordingly. So, for example, one of our clients had an immediate issue with something on their website, which fell into our bucket of responsibility. We asked the client to prioritise it, then logged it as a bug, and had it finished according to its urgency.

Rather than grouping items by project — considering that some clients have multiple projects with us — epics and components are client-​level rather than project level. An epic is a set of user stories that we are working on at any given time. It gives us a higher view and a higher level of control.

Story points versus time spent: Effort or hours?

As with probably every service provider, we started out estimating jobs by hours. But these estimations were never accurate. They would be wildly over-​estimated, or wildly under-​estimated. Jobs would take up the time that they were allocated. And we felt pressured constantly, which is not a happy way to work.

So, with a great deal of hesitation we threw hours out the window and welcome story points to the family.

How story points work

Story points, if you’re not aware of them, are allocated to each user story. They are a comparative measure, based on the other items that need to be done. It says, compared to this task, how much effort will this take? You could easily assume that the ones with higher points will take longer, and that’s often the case. But effort also comes in the shape of increased complexity, more barriers, more consultation, and so on. These are the things that hours estimations can’t effectively deal with.

In order to simplify the allocation of points, we use Fibonacci numbers (0,1,1,2,3,5,8,13,21), and eliminate duplicates and zeros from the scale. (Realistically, if it takes no effort at all, it’s already done.) Therefore, our story points allocations are 1,3,5,8,13,21. And there’s a rule that if it’s as gigantic as 21, then it needs to be broken into smaller parts.

Since moving to a story points methodology, our progress charts (burndowns in scrum) are actually meaningful. The charts say, this is how on track you are for seeing how much effort you can expend in a given timeframe.

It will take us a while to get 100% clear about how many story points we can reasonably cram into a week. The beautiful thing about scrum is that it gives you a picture of your velocity: The speed at which points are completed. When we’ve been doing this for a while longer, we will have a crystal clear picture of how many points we can achieve in any given week. And by that point, our existing capacity will be matched with our work schedules and project planning.

Then, if demand goes up, we know exactly what kind of additional effort we need to bring in, recruit for, or otherwise deal with.

And after all of this, what’s the result?

Our time spent in administration is really low because a major amount of that administration is kept with the cards in JIRA. Our Plans and Updates are auto-​captured by Podio. User stories in sprints automagically complete themselves when all the tasks are done.

Comments and adjustments on sprint setup that come from clients are adjusted on the Podio Plan for that week. Notes out of in-​sprint communications are kept on the file, too. Thus, client accounts have all the important communications attached to them, and are easily discoverable. Between Podio & JIRA, we can see at a glance what we promised to deliver, what we’ve actually done, and how much effort it’ll take to complete it. The sprint review gives us a chance to see whether the job will be done on time.

Our clients love the fact that they have full visibility over the work we have in progress for them, and we all feel fantastic about the fact that we’re working collaboratively, productively, and have a clear grasp of expectations.

But the best thing? It’s fast, flexible, and just works to keep us moving. Ultimately any efficient project management framework has similar success criteria. Would love to hear your thoughts about how we work! Leave a comment and let us know.


Leave a Reply

Your email address will not be published. Required fields are marked *