How do you handle tasks that could span many sprints?

This is a question that often comes up when people start looking at an agile framework like Scrum. Scrum sets out various roles, meetings and events to set up in order to use the framework, and one of these events is called a sprint.

A sprint is in essence just a timebox, a chunk of time within which a team will aim to complete a certain number of things. Technically, a sprint can be one month long or less, but you typically find Scrum teams run sprints that are between one and three weeks long. The sprint starts with a planning meeting, to plan what to do in the sprint, and ends with sprint review and restrospective meetings, to inspect what was done and how it was done, with a view to improving each of these things in the next sprint.

The problem this creates for some teams though is that they're used to working on things that take longer than one to three weeks to deliver, that even take longer than a month to deliver. When you've got work like that, work that could stretch across many sprints, what do you do?

Well, the incorrect but all too common answer is just to roll things over from one sprint to the next. So at the end of the sprint you just tell people you worked on this task, then at the next sprint planning meeting you pull the task into the next sprint, and just carry on. This is dangerous for a whole number of reasons.

The more you just roll things over and work on them for long periods of time, the longer you're waiting to get feedback on them. The longer you wait to get feedback, the higher the chances are that you're building the wrong thing, or building it wrong. Agile is all about being able to respond to change and new information by continuously running experiments, getting feedback and learning about what you're doing.

On top of this, large tasks that take many weeks or months to complete provide much less visibility into what is going on, which makes spotting problems and fixing them much more difficult. Transparency is a crucial part of many different agile frameworks, and for good reason. You have to make things visible in order to inspect them and adapt them. If a piece of work is just written up at a very high level as one big task, and it gets delayed, it's much harder to see which element of the overall task it is that is causing the delay, and as a result it's much harder to do anything about it.

Finally, by waiting weeks or months for the whole task to be complete, you're delaying the point at which the thing you're building could start to be put in the hands of customers, and start making you some money. All the time you're holding onto a piece of work, it's just costing you money to store and maintain. As soon as you can release that piece of work to customers, it stops costing you money and starts making you money instead.

So what's the answer to these three problems. Well, it's the same answer for all three, and the same answer to the age old question, 'How do you eat an elephant?'. Simple, you just break it down into smaller chunks. Once you start to break tasks down, you can start to finish them and get feedback on them more quickly, get greater transparency into which tasks exactly are the ones that are slowing everything down, and you can start to get things shipped to customers and start making some return on your investment.

But how do you break tasks down? Often some tasks look like they can only ever be big, and even if you can identify all of the different 'sub tasks' that are involved, you still feel like you need to complete them all before you can show anything to anyone, or ship anything to a customer.

The answer to this comes in a practice often called 'story splitting' or 'vertical slicing', which is a series of techniques for identifying a simple version of the overall task, delivering that, then identifying the next most simple version of it, delivering that, and so on.

For example, in The Lean Startup, Eric Reis describes the story of Nick Swinmurn and Zappos shoes. Nick thought there might be money in an online shoe store, but rather than build the entire store before launching it to customers (a big monolithich task), he set up a simple website, went to local shoe stores, took pictures of their shoes and put the pictures and prices on the website. If people bought a pair of shoes via the site, he went back to the store, bought the shoes, and mailed them out to the customer. It wasn't a sustainable model, but it gave him feedback early on as to whether it was worth continuing with the idea. Turns out it was, and Zappos is still going strong.

That's just one approach to slicing up the elephant, there are a number of different approaches you can try documented here.

This is not to say it is easy. Breaking work down into smaller chunks can be tricky when you first start out, and you're so used to working on big tasks that take many months. It's a crucial one to start to tackle though, as without it, you'll be locked out of so many of the benefits an agile approach can provide.