Introduction to Task-Driven Development

The task workflow.

The next figure shows how the task workflow works, and its relationship with the entire Scrum process. The tasks I refer to are the ones you use when you decompose the user stories during sprint planning.

The task workflow

Version control sits at the center of the graphic as coordinator of the entire picture, but let's see what the main components are:


What are tasks? Everything will be a task, and tasks are managed by your favorite issue tracking system, as described in the previous topic. More importantly, tasks come from the product backlog (or whatever list of tasks or work breakdown structure you use).

Who uses tasks? Everyone! A developer can enter a task, just as a project manager can. Testers can introduce bugs, defects, and so on. The task is the central single-point for project coordination.


What are branches? They are the core of the developer's work. Developers will always work on branches, never on the main branch. Every task will always start from a well-known point, a baseline, or stable release (which closes the cycle).

Who uses branches? Developers, on their daily work. Integrators, when they need to create releases. Every task is tested and validated before marking it as "resolved" in your issue tracking system.


What is meant by integration? Once a number of tasks are finished, it's time to create a new release. Remember that "release early, release often" is a best practice worth following to avoid big bang integration (the root of all evil in the SCM world).

Who uses it? The integrators. Integrators can be developers playing the role once a week or once a day (depending on the release creation frequency). The integrator role can be a full-time job on big projects. Integrators not only merge the branches back to main, but are responsible of getting the build done right. They'll take a quick look at the code and they'll ask the developers for more information if something in the code is not clear, or if conflicts arise. Responsibility is key to the role of the integrator.

Note for continuous integration maniacs: Yes, there's life beyond continuous integration, and in fact, the branch-per-task pattern is the answer to the problems of the common CI. It even leverages it up to the next level. Check the previous link for info about the next steps mentioned in Duvall's book on CI.


What are releases? The integration result is a new stable release. Stable means it passes the entire test suite, so no known errors are left (or they're well-known).

Who uses them? The entire team. Once a release is finished, it can be passed to the testing group (if it exists). Developers will use the newly created release as the starting point of the new tasks they'll work on during the next working cycle.