When it comes to agile projects, one element of agile project management that is difficult for teams to master is how to overlap their work. If a team doesn’t learn effective ways to do this, team members may settle on a less desirable approach: activity-specific sprints. An activity-specific sprint is as bad a practice as it would be an acronym. In this approach, the team decides to use one sprint for analysis and design, a second sprint for coding, and a third for testing. The team is split in thirds, with the analysts working one sprint ahead of the programmers and the testers working one sprint behind them. This can be a very alluring approach. Not only does it seemingly solve the problem of how to overlap work but it also allows each type of specialist to work mostly with others of their own kind, which many may prefer until they become used to the close collaboration of a Scrum team. Unfortunately, the same disadvantages apply to activity-specific sprints as apply to activity-specific teams: too many hand-offs and a lack of whole-team responsibility.

One of the biggest problems with activity-specific sprints in agile projects is that they create what are known as finish-to-start relationships. In a finish-to-start relationship, one task must finish before the next can start. For example, a Gantt chart on a sequential project may show that analysis must finish before coding can start and that coding must finish before testing can start. Good Scrum teams learn that this is not true; many activities can be overlapped. In agile projects what is important is not when tasks start but when they finish. Coding cannot finish until analysis finishes and testing cannot finish until coding finishes. These are known as finish-to-finish relationships and are reinforced by Scrum’s sprint mechanism. All work is done at the end of the sprint, or it is returned to the product backlog.

With a little experience, most teams are able to see how to overlap some types of work and create finish-to-finish relationships between them. Teams easily find ways to overlap discussions of what users need and programming. They also soon find ways to overlap programming and testing. These activities lend themselves to iterative and incremental approaches: Get a few details from the users about what they need and then build a little of it; build a little and then test what you’ve built. Other activities, though, do not appear at first to be as amenable to an iterative, incremental approach. User experience design, database design, and architecture are often cited as work that needs to be done up front because the work must be viewed holistically. I argue that we should think holistically but work iteratively toward solutions. All sprint activities can and should overlap in agile projects.

For specific agile projects guidance on how to overlap work in a sprint, see Chapter 14, "Sprints," in Succeeding with Agile.