Most of the teams I’ve worked on have been not so great at breaking down the work that lands on the development backlog. There are plenty of resources out there on what stories are, and multiple different ways of writing them. There’s also articles written about different story splitting techniques. I couldn’t find anything out there about deliberately applying the theory however so I thought I’d write something.

Sometimes we just don't know how to begin breaking down work.

Before I dive in, lets start with some definitions

Epic – Also known as a “very big” story, that is unlikely to be completed in a single sprint or planning cycle. Would normally be broken down into several stories before being pulled onto a backlog. Epics can also be used for defining the main focus of a development team for a series of sprints.

Story – A smaller piece of work that can fit into a sprint or planning cycle specifically aimed at providing value to the end user and/or the customer. It can be good to apply the INVEST criteria to any story that you’re writing or at the very least include some acceptance criteria to define when a story is complete. Typically a story would be written in non-technical language to make it accessible for all interested parties to discuss. There are lots of different ways to write stories, Here’s a link to some sample formats.

Task – Pieces of a story that describe how the story is going to be achieved. These are usually written by the people doing the work. They should generally be short lived and completed within the sprint or planning cycle.

Splitting patterns

When examining a story (or an epic), you’re going to need to break it down. This has already been written about in much more detail over here. To keep things simple, I’ve summarized some of the commons ones:

  • Most difficult bit first (What’s the hardest piece of the story to solve?)
  • Simple case first (What’s the simple solution to the story?)
  • Functional first (Make it work, worry about performance later.)
  • User flow (What’s the first thing the user does. What’s after that?)
  • Per use case (What does user A want to achieve? User B?)
  • Per operation (buy a subscription, change a subscription, cancel a subscription)
  • Spike (What questions do you need to answer in order to know more about the solution?)

This is great! We now have some lines of thought we can use to think about our stories. We need to practice using these deliberately so as to get used to using them naturally and to ensure we don’t fall into the trap of using one or two of them over and over again.

Kata

Much in the same way as you’d practice different coding techniques in a coding kata, you can practice breaking down stories into tasks in a similar way. There is a little preparation to do in advance of your task break down kata.

Before you start, you’ll need to define some problems to split up. The problems should be large enough that they can be solved with multiple steps. Some examples might be:

  • Make a banana split
  • Go on holiday abroad
  • Buy something from an online store
  • Set up a new computer for a relative
  • Organize a party.

Try to work out if your problem is an epic or a story. If you’ve picked an epic, can you split it and write each story against the INVEST mnemonic? You want to end up with a few stories that can the broken down during the task break down kata.

Running the session

Split up in to groups of 2-3. Participants should be anyone that needs practice breaking down stories into tasks. If you can, try to make sure there is a mix of disciplines breaking down the selected story.

Choose a splitting pattern from above or from elsewhere, then take 10-15 minutes to apply the pattern to break down one of the stories. After you’ve applied the pattern, try to think around the edges and work out what was missed. What else needs to be included to make the story “complete”?

If you have lots of participants, compare and contrast results with other groups in the kata. Once you’re done you can try splitting the same problem again using a different pattern or use the same pattern on a different problem. Some problems will lend themselves better to one type of splitting pattern that others. Just keep practicing and you’ll get better at knowing which pattern to use for what kinds of problem.

lap top, headphones: remote work important tools

fully remote working: my work station for a whole week

In the first week of December I ran an experiment: our entire team was made to work remotely from the two main offices. The aim of the venture was for everyone to feel exactly what our remote employees feel every day. As a result, we hoped to improve team communication, both within the team and external to it.

Our team is probably one of the most distributed engineering teams in Metail. While most of our engineers are in the Cambridge office, a few work remotely. We’re lucky enough they are in the same time zone as the headquarters. Nonetheless we still suffer a lot of the pains that distributed teams feel, especially when the rest of the company is more used to working between the two offices, based in Cambridge and London.

Our hypothesis was that we would probably miss out on a lot of incidental “water cooler” conversations. We also guessed that communication with the rest of the organisation would be somewhat difficult.

Before Kick off

Before we rolled out the experiment, I had to lay some groundwork. Firstly I checked with our crew director (we work in teams called ‘Crews’ at Metail) and the other engineering managers that this wouldn’t impact anything crucial. We communicated widely across multiple channels that our team would be entirely remote during the week before the start date. I also spoke to the team to hear their concerns. It certainly helped to draw up a few guidelines. This is in summary what we came up with:

  • We use Slack by default and Skype as a backup
    • We say when we are at our keyboards and when we’re not
    • Everyone is to use headset and have their webcams turned on.
  • In general we try to ensure that we are over communicating
  • If there is a problem or someone can’t be reached, people are to come to me (the engineering manager) or our crew director.

There were a few practical things to take care of as well. We made sure our contact details were added to all the meeting rooms’ Skype accounts. We also checked we could all access internal resources via the VPN. Just to be sure, we ran a couple of trial calls to make sure Slack and Skype would work for us (they did!).

So how did it go?

We were able to anticipate the problems we hit; there wasn’t too much of the unexpected. It was much harder to run work past people on a casual, in person basis. Attempting to do so required both parties to mic up and jump on a Slack call.

Meetings with the wider company is where we struggled the most. We noticed people in Metail occasionally talk over one another and because of this it was hard to participate in guilds and other group meetings. Usually it meant one person in the office would drown out another who was further away from the room mic. We also noticed that if there were multiple people in the office participating in a meeting, remote workers often ended up ignored. In some cases it was difficult to observe body language that would normally be cues for a person to start talking. From time to time it was hard to hear people in the office. Sometimes this was because of problems with the audio equipment, other times it was because of background office noise.

We encountered a few minor technical issues as well. Some of these things were easy to fix, like tweaking rules on a firewall. Others were harder to diagnose, like why a developer was seeing Jenkins time out during load, preventing him from being able to see when builds were finishing. A couple of times we had issues with Slack where one person in the group couldn’t see another but these were easily fixed by leaving the call and re-entering it.

Generally speaking the engineers found it easier to focus on the work they were attempting to do. On the other hand it was pretty difficult for myself and our crew director, being the main communications interface between the team and the rest of the company.

I also discovered that my house gets really cold during the day if I don’t put my heating on! I made a special effort to be a little more social, going out to dinner and to the pub for much needed social interaction.

Conclusions

On the Monday following the experiment we ran a retrospective where we recorded our experiences. On the whole, the world didn’t end and the company kept working. We recognise that it was a pretty short experiment, lasting only a week, but we still found it valuable. One thing we noticed was that we certainly affected how the rest of the company interacted with us by communicating that it was coming up. I can now say I have a much better understanding of the pain our remote colleagues go through every day. I’m definetely going to be reminding people in the office about it in the future.

Learnings

If you engage with remote employees or are planning to in the future, here is what I’d recommend:

  • When you are having a meeting with remote people and it’s possible for everyone attending to have mics, then do so.
  • Let remote employees know if you are starting a meeting late.
  • Respect meeting etiquette and allow all attendees to fully express themselves. Don’t interrupt until they’re done speaking.