I recently had a lively discussion with my fellow agile coaches on whether it’s a good idea to break Product Backlog Items (PBIs) down into tasks or not. In practice, a lot of teams use this technique.

According to the 14th annual state of agile report (p. 15), 66% of Agile Teams use a taskboard to manage their day-to-day activities. While this number doesn’t specify whether they use tasks or not, I think we can assume that’s the case. But what does the Scrum Guide say about that? Is it really a good idea?

What’s in the Scrum Guide?

While there is no occurrence of the word “task” in the Scrum Guide, we can find some references that can be easily associated with this practice. Let’s dig deeper into those!

The Sprint Backlog

First of all, regardless if the team uses tasks or not, we have to understand what is a Sprint Backlog exactly.

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. […] The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.” — The Scrum Guide (2017)

Teams tend to associate Product Backlog and Sprint Backlog. For a good reason, though: they both use the term “backlog”. However, while the Product Backlog is explicitly described as an ordered list of Product Backlog Items, the Sprint Backlog is composed of two different components:

• Product Backlog Items selected for the Sprint
• A plan that links the PBIs to the Sprint Goal and describes how the team will deliver the product Increment

This plan is what interests us today. We want to determine how the team will deliver the product Increment.

The plan

“Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.” — The Scrum Guide (2017)

During Sprint Planning, the Development Team builds the firsts bricks of their plan, at least for the first days. The idea here is to get sufficient detailed units of work so the team can monitor progress towards the Sprint Goal during Sprint execution, during the Daily Scrum. Tasks seem to be a good way to handle this.

Note there is no mention of the Product Backlog Items here, the “work” is decomposed. Does it mean the team can group together a few PBIs and decompose the work for them? Well, yes! As soon as the team is able to efficiently self-organize to deliver a “Done” product Increment before the end of the Sprint, why not?

That doesn’t look like a good practice, though. How do you shorten the feedback loop on the product Increment if you are only able to deliver it at the end of the Sprint? Finding the right balance between focus, efficiency, progress monitoring, flow management and continuous value delivery is an important area to focus on.

Sprint execution

“The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint. […] By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.” — The Scrum Guide (2017)

The decomposition doesn’t have to cover the entire Sprint, but at least the first few days. However, the Development Team has to have a plan to handle work that will emerge during the rest of the Sprint. Daily Scrums are key opportunities to inspect progress and adapt (or build) the plan incrementally.

Applying the Lean principle of “just-in-time” can help teams discuss just enough details at the right time without putting the Sprint Goal at risk. Self-organization doesn’t mean “we’ll see”. It means the people who perform the work decide on how they will organize to achieve their goals. They should be able to explain their plan to others.

Task boards, Scrum boards, Kanban boards and visual management, in general, are part of the Sprint Backlog and are a representation of how the Development Team intend to self-organize around the work to be done. They can be considered as the plan and as so, include all the details needed to perform the work. Or the team may decide to create a separate plan. They decide but make it transparent, anyway.

Forecasting

“At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.” — The Scrum Guide (2017)

Estimation and forecasting are an integral part of Scrum and I will not question them here (maybe in a future article). However, the Scrum Guide doesn’t specify how the remaining work should be estimated. Neither does it specify what should be summed. Do we talk about PBIs or units of work? Or even workflow and process?

We talk about work. We talk about the big picture: how much work is still required to deliver the product Increment (as described in the definition of “Done”).

Should the estimates be expressed in time? in story points? in number of headaches? That’s up to you! As well as how the team tracks its progress and likelihood of achieving the Sprint Goal. Burn-up or burn-down charts, cumulative flow diagrams, or even Kanban boards with historical cycle times may be good candidates.

“The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.” — The Scrum Guide (2017)

Finally, work will emerge during the Sprint. The plan built during Sprint Planning will change and the road towards the Sprint Goal will be paved as the team goes.

How to write better tasks

I have to admit it before I go further: I’m not a big fan of tasking. I’ve seen many teams using tasks as a way to distort good agile practices.

For example, PBIs estimated in story points and tasks in hours, or INVEST PBIs with each task focusing on only one layer of the software (e.g. “create tables in database”, “create UI”, etc.), or even worse: they use tasks to divide the work in order to avoid collaboration…

Nevertheless, teams need time to learn by themselves how to self-organize. Junior teams may find it useful to use tasks in order to have a better vision of what needs to be done and organize the work. Tasks are manageable units of work that may ease team self-organization and forecasting.

Still, how to make sure we don’t switch our focus from “how do we deliver great value” to “how do we execute tasks according to the plan”? How do we shorten the feedback loop? How not to waste too much time on administrative stuff? How do we foster collaboration?

Transparency

Let’s begin by trying to better visualize the team’s workflow. One thing I’ve noticed repeatedly is Development Teams using tasks as steps to complete their PBIs in order to put estimates on each of them. But these are not tasks, these are workflow steps. So why not using them more effectively and help the team visualize their workflow?

Transparency is the foundation of empiricism which allows for inspection and adaptation. This activity will usually lead the teams toward a better proto-Kanban board.

Now remains the problem of estimation and forecasting. Measuring each step of the workflow as well as the total time required to get a PBI done can help teams provide more accurate estimates of what needs to be done and better track progress during the Sprint.

Feedback-driven tasks

At this point, the need for tasking should have significantly reduced while staying compliant with the Scrum Guide. But let’s go further! Scrum events are key opportunities to inspect and adapt continuously to different cadences.

The most frequent event is the Daily Scrum and it happens on a daily basis. But that doesn’t mean there is no need for inspection and adaptation in between! Tasks can also be used as an attempt to shorten the feedback loop.

The purpose of feedback-driven tasks is to divide the work in order to get fast feedback. That means creating the minimum viable piece of value required to validate a direction for the next minimum viable piece of value until the entire value (PBI) has been delivered.

Extremely small INVEST units of work will dramatically improve the quality and relevance of the product Increment while ultimately reducing the time needed to complete the work.

It may be counter-intuitive for some, but by focusing on few items and getting them done while completing the feedback loop multiple times, teams will reduce both integration issues and back-and-forth discussions on whether the solution seem relevant or not.

Let’s take an example for better clarity. Imagine you want to create an authentication system in order for your users to get a customized experience on your product. That’s your PBI. Now, what could we do to shorten the feedback loop? We could start building the simplest possible scenario: e.g. a connection form with valid email and password.

Then, ask for code review and integrate it in the main development trunk in order to check if it breaks something (technical feedback), and ask the Product Owner or the customer for feedback about the solution itself.

Based on these feedbacks, the team will adapt the plan and decide on whether they continue or orient it in a different direction (i.e. Sprint Backlog emergence). Then, they could start implementing other business rules, such as a wrong email or wrong password, etc. Feedback. And finally, they could improve the error handling system to have it more user-friendly…