When using Scrum, the Sprint Backlog is often seen as the batch size. A pattern we often see, and something that we want to minimize as much as possible, is a Scrum Board that looks like this:

You'll notice that almost every single User Story is in play, which probably means that each member of our team is working on something different. This is often a symptom that our team isn't working together, but as individuals, within their specializations—user experience designer, graphic designer, developer, frontend developer, tester.  

Each specialist will go through the tasks of a User Story to determine if there is some work they can do. Once they've moved through all stories on the board and consider their tasks "done," they then look at the Product Backlog to see if there is any further work that fits their specialty.

In this scenario, when a software developer considers the coding is complete for one particular User Story, they then move onto the next User Story for the next piece of coding, and so on. This practice causes a few knock-on effects:

• Handoffs: Handing work over between the specializations, in this case between the software developer and the reviewer or tester, is wasteful regarding knowledge and time lost during the transfer. This also includes a transfer of responsibility where, like a game of software development tag, the last person who touches the software becomes responsible.
• Interruptions: The team member will need to be pulled off what they're currently doing to fix any problems brought up by either testing or review. There will likely be several iterations of reviewing, testing, and bug fixing.
• Waiting in queues: Queues of work start to form. For instance, all the coding is getting done super quickly because all of the developers are so busy coding. So busy, in fact, none of them are stopping to review each other's code or fix any problems the testers have raised. This leaves each of those User Stories open, with a status of "in progress" on the board, when in fact nobody is working on them.
• Multitasking: Despite all best intentions, the lack of synchronization between team members will cause people to be pulled from one task to another to perform handovers or reworking.

When a team works this way, if we lay out each task in sequence it will look a little like a production line, except instead of having just one production line, we have one for each User Story. The previous person in the line believes they've completed their work and hands it over to the next person to do theirs; they then start the next User Story and open a new production line. However, making software is not a linear process, and it won't be long before each team member is being pulled from one User Story to another.

Handoffs are especially apparent to the test role. They are often the last people in the process before deployment, and therefore the ones under the most pressure—pressure to get testing done and pressure not to find problems (or if they do, depending on how significant the problems are, to accept that they could be dealt with in another round and to let the software go out in a compromised form).

Thinking in terms of job specializations tends to put us into boxes. It makes us think that business analysts only gather requirements, software developers only write code, and testers only test it. This isn't team thinking; this is individual thinking.

At worse, it causes an abdication of responsibility, where people only feel responsible for their part of the User Story, rather than the User Story as a whole. This approach is little more than a mini-waterfall. It still shares the same problems associated with cascading work, albeit on a smaller scale. 

To accommodate "vertical slices" of useful software, we have to change our workflow. Each User Story becomes the whole team's responsibility. Remember, Scrum intends us to work together to get the ball across the line. The distinction between frontend, backend, UX designer, and tester starts to blur.

To focus on flow, we have to consider the system as a whole, from the point when we start to work on an item to the point where we deliver it. We look to optimize the end-to-end delivery of items in our flow through the close collaboration of our roles.

One way to improve team cohesiveness and focus is by limiting the amount of Work In Progress (WIP). How do we do this? There are two schools of thought:

• Reduce work in progress limits to a minimum; allow the team to get a feel for flow over several items of work, then if necessary increase WIP gradually to see if it increases flow or decreases flow.
• Don't set any WIP limits and watch what naturally happens; if a logjam starts to form, reduce the WIP limit for that particular column.

The aim of limiting WIP is to reduce the amount of multitasking any one team member has to do. As we've already mentioned in Chapter 2, Agile Software Delivery Methods and How They Fit the Manifesto, one definition of multitasking is "messing multiple things up at once."

This isn't just an approach we use for Kanban. We can apply this to Scrum as well, by merely applying a WIP limit in our in-progress column.

There are team configurations that will help us naturally limit WIP:

• Pairing: Two Development Team members work together on one User Story, taking it from end to end across to the board. See Chapter 7, Software Technical Practices Are the Foundation of Incremental Software Delivery for more on Pair Programming.
• Swarming: A temporary burst of the whole team's power, used to get over humps. For instance, to move all the User Stories waiting to be tested, everyone rolls up their sleeves and starts testing. Once we've gotten over the hump, the team then tends to return to their standard configuration.
• Mobbing: The whole team's power applied to one User Story at a time. Unlike swarming, the team tends to stay in mob configuration to see a piece of work through from start to end. Some teams work in mobs permanently, giving them a WIP of one User Story at a time. See Chapter 11, Improving Our Team Dynamics to Increase Our Agility for more on Mob Programming.

In each of these approaches, people work much more closely together. Software development is about end-to-end delivery. Cross-pollinating and understanding each other's skill sets by literally working together creates better software and most likely sooner. Working this way also avoids hand offs and context switching as much as possible

This is a move from optimizing our "resources" to optimizing our workflow, which at the end of the day achieves what we wanted—increasing the flow of value we deliver to our customer, which in our case is in the form of working software.