Task Planning

Audience

Whole Team

We have a plan for this week’s work.

If you follow the practices described in the “Planning” chapter, you’ll end up with a visual plan with multiple levels of detail: valuable increments that could possibly be done in the long-term, small valuable increments that are likely to be done in the medium-term, and specific stories that will be done in the near-term.

That plan turns into action through task planning: breaking down stories into tasks and tracking the team’s progress. Because Agile teams are self-organizing (see the “Key Idea: Self-Organizing Teams” sidebar), task creation, assignment, and tracking is done entirely by the team, not by managers.

There are three parts to task planning: cadence, creating tasks, and visual tracking.

Cadence

Cadence is the frequency of your task planning. There are two common approaches in the Agile community: iterations (also called Sprints¹) and continuous flow (also called Kanban).

¹“Sprint” is a misleading name. Software development is more like a marathon than a series of sprints. You need to work at a pace that you can keep up indefinitely.

Iterations are fixed-length timeboxes lasting a week or two. At the beginning of every iteration, you choose a set of stories to complete, and by the end, you expect them all to be done. Continuous flow, in contrast, is an unending stream of stories. You choose a new story whenever the previous one is finished.

Allies

Capacity

Slack

Teams new to Agile should use iterations. Not because they’re easier—they’re actually harder—but because the strict iteration cadence provides important feedback about how the team needs to improve. More importantly, when used correctly, your iteration capacity gives you the slack to make those improvements.

Continuous flow doesn’t have the same built-in opportunities for improvement that iterations do. It’s harder to notice when your team is going off the rails, and harder to justify spending time on improvements. That said, continuous flow is less stressful and many teams prefer it.

Iterations

Software development dies in inches. At first everything’s fine: “I’ll be done with this task once I finish this test.” Then you’re limping: “I’ll be done as soon as I fix this bug.” Then gasping: “I’ll be done as soon as I research this API flaw...no, really.” Before you know it, it’s taken you two days to finish a task you expected to take two hours.

Death by inches sneaks up on a team. Each problem only takes hours or a day, so it doesn’t feel like a problem, but they multiply across the hundreds of tasks in a release. The cumulative effects blindside teams and their stakeholders.

Ally

Done Done

Iterations allow you to detect problems early. They’re strictly timeboxed: when the time is up, the iteration is over. At the beginning of the iteration—each is typically a week or two in length—you predict your capacity and choose stories to match that capacity. At the end of the iteration, all the stories should be “done done.” If they’re not, you know something went wrong. Although this doesn’t prevent problems, it reveals them, which gives you the opportunity to fix the underlying issues.

Allies

Stakeholder Demos

Retrospectives

Continuous Deployment

Iterations follow a consistent schedule:

1. Demonstrate results of previous iteration to stakeholders (half an hour)

2. Hold retrospective on previous iteration (one hour)

3. Plan iteration tasks (half an hour)

4. Develop stories (remainder of iteration)

5. Deploy, if not using continuous deployment (automated)

Many teams start their iterations on Monday morning, but I prefer iterations that start on Wednesday or Thursday morning. This allows team members to take a long weekend without missing important events. It also reduces the desire to work on the weekend.

Iterations can be of any length, but most teams use one- or two-week iterations. For teams new to Agile, one-week iterations are best. That’s because teams develop their understanding of Agile based on how many iterations they’ve undertaken, not how many weeks they’ve experienced. Shorter iterations result in more rapid improvement.²

²I’ve taught classes where students develop real software in 90-minute iterations. They experienced the same improvement I’ve seen from teams using week-long iterations.

Allies

Energized Work

Refactoring

Capacity

On the other hand, one-week iterations put more pressure on the team. This makes energized work more difficult and can dissuade people from refactoring. Capacity is harder to predict in one-week iterations, too, because interruptions and holidays are proportionally bigger interruptions. So, once your team is able to reliably finish its stories every iteration, go ahead and experiment with two-week iterations.

Iterations longer than two weeks are usually a mistake. Teams use longer iterations when they feel they need more time to get their work done, but that’s just papering over problems. Longer iterations won’t change the amount of time you have; they change only how often you check your progress.

If you have trouble finishing stories, use shorter iterations and make your stories smaller.

If you have trouble finishing everything by the end of the iteration, it’s not because you need more time; it’s because you need more practice working incrementally. Shorten your iteration length, make your stories smaller, and focus on solving the problems that prevent you from finishing stories.

Continuous flow

Continuous flow is just what it sounds like: a continuous flow of stories with no particular start or end. Rather than predicting what your team can do each week, establish a “work-in-progress limit” for how many stories your team will work on at once. One to three is best. The fewer, the better. (See the “Key Idea: Minimize Work in Progress” sidebar.) Once the limit is reached, no more stories can be started. When a story is “done done,” it’s removed, making room for a new story.

In theory, continuous flow is less wasteful than iterations, because you don’t need to predict capacity or make stories fit within the iteration timebox. In practice, I haven’t found that to be true. A strict iteration timebox keeps the team focused on completing stories. Teams using continuous flow don’t have the same urgency to fix problems and cut scope. I recommend that teams new to Agile master iterations before trying continuous flow.

That said, continuous flow can be a good fit for teams with a lot of small, unpredictable stories, such as teams doing a lot of maintenance and bug-fixing work. If your plans are changing so often that even a one-week iteration is too long, continuous flow is a good choice.

Key Idea: Collective Ownership

Agile teams share responsibility for results. The whole team works together to get stories done, with each team member fluidly taking on the work they know best, assisting people who need help, and learning how to contribute to work they don’t yet know well. If something goes wrong, the team works together to solve the problem; if something goes well, the team takes credit as a whole.

Some teams assign stories to individual team members to work on independently, but the best Agile teams “swarm” their stories. They tackle one story at a time, or as close to one at a time as they can manage, coordinating and collaborating so that everything comes together. By doing so, they avoid the risk of one person getting stuck and derailing progress without the rest of the team knowing.

On Delivering teams, this shared ownership extends to code, too. The “Collective Code Ownership” practice describes how it works.

Creating Tasks

Allies

Capacity

Visual Planning

The Planning Game

Start your task planning by choosing stories. If you use iterations, choose stories based on your iteration capacity: for example, 6 stories, or 12 points. If you use continuous flow, choose stories according to your work-in-progress limit, then plan a new story whenever a story is finished. Either way, choose only stories that are ready to be completed: third-party dependencies have either been resolved or the third party is ready to participate.

On-site customers choose stories by taking the highest-priority stories from the visual plan. They spread them out on a table, or virtual whiteboard, and explain them to the rest of the team. This should only take a moment: the team will have already seen the stories during the planning game.

Next, use simultaneous brainstorming (see the “Work Simultaneously” section) to come up with the tasks needed to complete each story. Make them small: a few hours of work each. Write each task on a card, or virtual equivalent, and put it next to the story it relates to.

Tasks can be anything you like. Everything needed to finish the story should be included. Examples include “update build script,” “add Customer class,” and “mock-up billing form.” Most tasks will be created by developers, but anybody can participate.

Task planning is a design activity.

Task planning is a design activity. It’s a way of getting the whole team on the same page. If everybody has the same ideas about how to develop the software, it should go quickly. If not, it’s a great opportunity for discussion before development begins.

You don’t need to go into a lot of detail on each task. Task planning is about getting everybody on the same page, not exhaustively deciding what to do. Leave room for people to work out details when they do the work. For example, if one of your tasks is to “add Customer class,” you don’t need to say which methods it includes, as long as the programmers all understand how the Customer class fits into the plan.

As you work, developers may have questions about the details of each story. Make sure team members with customer skills are on hand to answer those questions.

Creating your task plan should take less than 10–30 minutes. If it takes longer, you’re probably going into too much detail. If there’s a question you’re getting stuck on, don’t solve it during the meeting. Instead, add it as a design task of its own. For example, if people are trying to decide which authentication library to use, add a task that says “choose authentication library.”

Remember that the team should collectively own its work. If you create design tasks, be sure all the team members affected by it have a voice in those decisions. They might work on the task together. Alternatively, the team can delegate the task to a subset of people who come up with options, then report back to the larger group. Either way, it’s something to do after the initial task planning meeting.

The outcome of the task planning meeting is your initial set of tasks. As you work, you may discover new tasks. This is particularly likely when you have a design task. For example, a “choose authentication library” task might result in new tasks such as “create authentication callback endpoint,” “write password reset email copy,” and “add reset email to deploy script.”

Once all the tasks are ready, double-check whether the plan has everything the team needs to finish its stories. Ask the team if the plan is achievable. It usually will be, but if it isn’t, remove or replace stories until it is.

Ally

Stand-Up Meetings

Finally, conduct a consent vote (see the “Seek Consent” section). When the team consents to the plan, you’re ready to go. Set up your task tracking board, hold a brief stand-up to decide what people will do first, and get to work.

Visual Tracking

Agile teams share ownership of their work, as the “Key Idea: Collective Ownership” sidebar describes. Tasks aren’t assigned to specific people. Instead, when somebody’s ready to start working on a task, they look at the tasks available and choose the next one that they can contribute to or learn from. It’s the whole team’s responsibility to keep track of progress and help out where needed.

Ally

Informative Workspace

It’s easy to fixate on your own tasks at the expense of the team’s overall progress. Remember to stay aware of the broader picture, and to put the success of the team over finishing your individual tasks. Stand-up meetings will help you step back and think about the big picture, but an even more important tool is your task tracking board. It’s a central part of your informative workspace.

My favorite tool for task tracking is a large magnetic whiteboard. I like to use a six-foot whiteboard on wheels. I put the visual plan on one side and the task plan on the other. If your team is remote, you’ll use a virtual whiteboard. It’s often most convenient to put your task plan and visual plan on the same virtual board.

The task board is the nerve center of your team room, whether physical or virtual. It makes your progress visible at all times. Be sure to keep it up-to-date. When you start working on a task, mark the board with your name or initials. In-person teams often create custom magnets with fun pictures for this purpose. Remote teams can upload custom images.

In a physical team room, bring the task card back to your desk. The act of physically moving to the board and taking a card will help the rest of the team maintain situational awareness. Just seeing people move around is a powerful tool for understanding the team’s status.

In a remote team, you can have the same impact on situational awareness by giving team members a tablet to use for their virtual whiteboards. (It’s a good idea anyway. Tablets are inexpensive and make whiteboard sketches much easier.) Leave the tablet powered on and logged in to the task board so you can see changes out of the corner of your eye. You can always turn it off if it’s distracting.

Keep your task planning approach visual and lightweight.

The best way to visualize your task plan is whatever works best for your team. Here, I present two options. Feel free to experiment with others. Keep it visual and lightweight, though, using a whiteboard or virtual equivalent.

So-called Agile planning tools, such as Jira, add too much friction. Agile teams constantly experiment with improvements and new ways of working. A planning tool will only get in your way.

Task grid

The task grid has been a hit with every team I’ve introduced it to. It’s simple and compact. To create it, arrange your stories vertically, with the highest priority story on top. To the right of each story, arrange the tasks associated with that story in a horizontal line. Put the tasks in whatever order seems most natural. It’s okay to complete them out of order.

Ally

Done Done

When people are ready to work on a task, they take whichever card they’re prepared to work on, starting from the top-left corner. As each task is finished, mark the card in some way: circle it with a green marker, mark it with a green magnet, or change the color of a virtual card. (Avoid writing on the card. Sometimes tasks need to be revisited.) When all the tasks for a story are done, the final task is to review the team’s definition of done, make any final changes needed, and mark the story card green as well.

Task grids work particularly well for teams using iterations. The “A Task Grid” figure shows an example.

Figure 1. A task grid

Detectives’ whiteboard

You know how, in crime dramas, there’s a whiteboard with all the information about the crime? Suspect mug shots, evidence, arrows going from one part to another? That’s a detectives’ whiteboard, and that’s exactly how this visualization works.³ the “A Detectives Whiteboard” figure shows an example.

³Arlo Belshee introduced me to the detectives’ whiteboard as part of his Naked Planning process.

Figure 2. A detectives’ whiteboard

Every story gets its own board, or part of a board, and everything related to the story is put on the board. Tasks, mock-ups, documents...everything. They’re grouped in whichever way makes sense to the team.

When a task or piece of information is done, or no longer relevant, the team removes it from the board. When team members realize something else could be helpful, they add it. The story is done when the board is empty. Detectives’ whiteboards work particularly well for teams using continuous flow.

Cross-Team Dependencies

Some stories may depend on work from people outside the team. Because stories are small—typically, only a day or so of work, if the team works together—it’s best to wait until these third-party dependencies are resolved. Similarly, if a story requires somebody to join the team temporarily, wait until that person is available. Otherwise, you’ll end up with partially completed work. (See the “Key Idea: Minimize Work in Progress” sidebar.)

Don’t choose stories with unfulfilled dependencies.

To be specific: when choosing stories for task planning, don’t choose stories with unfulfilled dependencies. If you’re using iterations, they have to wait until the next iteration. If you’re using continuous flow, they have to wait until the next slot opens up.

If you start work on a story and discover that it has a dependency, it’s okay to leave it in your plan. But put a short timebox on it, such as a day or two. If the dependency isn’t resolved by then, take it out of your plan and replace it. I mark such tasks in red, with an expiration date.

Some stories might need work from your team, work from another team, and then work from your team again. Split those stories into two stories: first, a story to prepare for the other team, and second, a story that you start after the other team has made its contribution. Remember to keep them customer-centric, as described in the “Customer Value” section.

Ally

Whole Team

In general, Agile teams should be able to take full responsibility for each story they develop. If your team faces a lot of delays due to cross-team dependencies, something is wrong. You might not have a whole team, or your organization might have chosen the wrong approach to scaling (see the “Scaling Agility” chapter). Ask a mentor for help.

Making and Meeting Iteration Commitments

Ally

Stakeholder Trust

Iterations are a powerful tool for improving your team’s ability to deliver software reliably. To take full advantage of them, treat your iteration plan as a commitment: something that you’re going to do your utmost to achieve.

At first, you’ll have trouble achieving your iteration plans, so make your commitment privately, within the team. Commit to yourselves, not stakeholders. With practice, though, you’ll be consistent enough that you can share your commitments with stakeholders, too—and that is an incredible way to build trust.

Commitments are a choice the team makes for itself.

No matter what, though, commitments are a choice the team makes for itself. Agile teams own their work. Managers, never force commitments on your teams. It doesn’t end well.

Of course, owning your commitments doesn’t mean you’ll always finish everything you planned. Things will go wrong. Yes, commitment is about doing what’s necessary, within reason, to finish the iteration’s stories on time, but it’s also about working around problems and being clear and honest in your communication when problems come up that you can’t work around.

Allies

Stand-Up Meetings

Done Done

Slack

To meet your commitments, you need to be aware of problems before it’s too late. During your daily stand-up meeting, review your team’s progress. Is there a task that’s been in progress since the last stand-up? It could be a problem. If you’re halfway through the iteration, are about half the task cards marked green? If not, you might not finish everything on time. Are half the stories also marked green? If tasks are done but stories aren’t, you could be blindsided by extra work to get stories “done done” on the last day.

When you discover a problem that threatens your iteration commitment, see if there’s any way you can change your plan to meet your commitments. Would using some of your slack help? Is there a task you can simplify or postpone? Discuss your options as a team and revise your plan.

Sometimes the problem will be too big to absorb. In this case, you’ll usually need to reduce the scope of the iteration. Typically, this involves splitting a story and postponing part of the work, or removing a story entirely.

Always stay in control of your iteration, even if you have to remove a story to do so. Any iteration that delivers all the stories in your current plan—even if that plan is smaller than it was at the beginning—is a success. But under no circumstances should you change the iteration deadline. Always end the iteration on time. It’ll keep you from fooling yourselves.

Incomplete Stories

Allies

Done Done

Capacity

At the end of the iteration, every story should be “done done.” Partially completed stories should be rare. That said, they will happen occasionally, particularly while you’re still learning.

Incomplete code is harmful. If you don’t plan on finishing a story immediately in the next iteration, strip its code out of the codebase and put the story back in the visual plan. If you do plan on finishing the work, create a new story that represents the work that’s left to be done. If you’re using estimates, give it a new estimate. You don’t want the partially completed work to count toward your capacity, because then you’ll just end up signing up for too much work again.

Sometimes, despite your best efforts, you could end up with nothing that’s completely done. Some teams declare a lost iteration when this happens. They roll back their code and start over as if the iteration never happened. Although this sounds harsh, it’s a good practice. Iterations are short, so you won’t throw away much code, and you’ll retain everything you learned when you wrote it the first time. The second attempt will produce better code.

If you’re having trouble finishing stories, change your approach.

Fluent teams rarely have unfinished stories. If you’re having trouble finishing stories, change your approach. Reduce your planned capacity, split your stories smaller, and coordinate as a team on finishing each story before moving on to the next. If that doesn’t help, something is wrong. Ask a mentor for advice.

Emergency Requests

It’s inevitable: you’re in the middle of finishing a story, everything is going well, and then a stakeholder says, “We really need to get this new story in.” What do you do?

First, decide as a team whether the story is really an emergency. Your next task planning meeting will typically be just days away. Rather than inserting chaos into the team’s work, maybe the new story can wait until the next opportunity. Team members with the most business expertise and political savvy should lead that decision.

If you do decide to prioritize the emergency story, your approach depends on whether you’re using iterations or continuous flow.

For iterations, you can remove any story that hasn’t been started and replace it with a story of the same size. (The removed story goes back into the visual plan.) If all of your stories have already been started, you can still remove stories, but you’ll have to guess about how many to remove, and you’ll have to take out their code. That way you don’t have incomplete code gumming up the works.

Teams using continuous flow often create a separate work-in-progress limit just for emergency stories. Keep the limit very small—one emergency slot is often best. If there’s a second emergency and it can’t wait, you can remove an existing story, but you have to take out its code.

If you have a steady trickle of small emergencies, you can treat them as overhead rather than stories. Put them on your task board, but don’t count them toward your capacity. Your capacity will automatically adjust to give you enough time to deal with the emergencies, at the cost of less time to work on stories.

If you have a lot of emergency requests, or other ongoing support needs, you can reserve a developer (or several) for taking care of those requests. In between requests, they can work on anything that’s not frustrating to interrupt—which typically excludes working on stories. Rotate a new person into this role every day or week to prevent burnout.

Your First Week

When your team first tries Agile, expect the first month or two to be pretty chaotic. During the first month, on-site customers will be figuring out the visual plan, developers will be establishing technical infrastructure, and everyone will be learning how to work together using Agile practices.

Some people think the best way to overcome this chaos is to take a week or two up front to work on planning and technical infrastructure. (This is often called “Sprint Zero.”) Although there’s some merit to this idea, Agile teams work on planning and technical infrastructure iteratively and continuously for the entire life of the team. Starting with real work on the first day helps establish this good habit, and helps keep the work focused on what’s actually needed.

Allies

Adaptive Planning

Visual Planning

The Planning Game

Start by using one-week iterations, and start your first day by planning your first iteration. Normally, this involves selecting stories from the visual plan, but you won’t have a plan yet. Instead, think of one valuable increment that will definitely be part of your first release and conduct a miniature planning game session for that increment. Come up with 10–20 “just right” stories that everyone understands well.

These first stories should sketch out a “vertical stripe” of your software, also known as a “walking skeleton.” They should build a tiny piece of every technology needed for your first increment, so you can see the software working for real. If the increment involves user interaction, create a story to display the initial screen or web page. If it includes a database, create a story to query a small amount of data. If it includes reporting, create a story for a bare-bones report.

Don’t expect much from your initial stories. Developers will need to establish their technical infrastructure. As a result, the stories should be very small. The initial screen might have nothing more than your logo on it. The database query might have hard-coded parameters. The report might display headers and footers, but no line items.

Allies

Capacity

Zero Friction

Done Done

Once you have your initial stories, you’re ready for task planning. You won’t know your capacity, so start by creating tasks for just one or two stories. Your first tasks will be to set up your technical infrastructure: version control, automated build, and so forth. Just do the minimum for now, as described in the “Automate Incrementally” section.

During the iteration, continue focusing on just one or two stories at a time, getting each completely done before adding another, until the iteration ends. The stories that are done will establish your capacity for the next iteration, as described in the “Your Initial Capacity” section. The ones that aren’t can be rolled back or turned into new stories, as described in the “Incomplete Stories” section.

Ally

Mob Programming

It’s a good idea to have programmers and operations work on the first few stories as a group, even if you don’t plan on using mob programming long-term. Set up a projector or shared screen so everybody can participate while people take turns controlling the keyboard. You don’t have to use a formal mob programming approach, but it could be helpful.

Working on your first stories as a group helps reduce the chaos that occurs when people start working together. It will help you jointly establish initial conventions, such as directory structure, filenames and namespaces, basic design choices, and infrastructure decisions. Individual developers or pairs can peel off to take care of some necessary issue, such as setting up version control or programming workstations, but for the most part you should work as a team.

Allies

Adaptive Planning

Visual Planning

Purpose

While programmers and operations are working together, on-site customers and testers should work on the visual plan. If you don’t have a draft purpose yet, start with that. Other team members can work with customers or developers as they see fit.

Each subsequent week will go a little smoother. Developers will learn how to split stories and customers will have a visual plan ready to pull from. The team’s capacity will stabilize. The feelings of chaos will subside and the team will begin to work in a steady, predictable rhythm.

Questions

How can task planning take less than 10–30 minutes? It always takes us much longer.

Ally

The Planning Game

The trick to effective task planning is to use it only for task planning. A lot of teams use their task planning session to estimate and break down stories, but it’s better to do that in a separate planning game session. Task planning should be focused on tasks. Your stories should be ready to go before you begin.

The other trick is to work simultaneously, using a freeform approach, instead of using an issue-tracking tool. (See the “Work Simultaneously” section.) Teams that use an issue tracker tend to bottleneck behind a single person controlling the tool, and that slows everything down.

With those two tricks, and some practice, your team should be able to easily finish task planning in less than 30 minutes. If it’s still slow, it may be because people are having trouble coming to agreement about what to do. Remember to create tasks for open questions rather than trying to resolve them in the task planning meeting. If that doesn’t work, ask a mentor for help.

How should we schedule time for fixing bugs?

Ally

No Bugs

Every time you find a bug, even if it’s not related to the stories in your plan, on-site customers should make a “fix” or “don’t fix” decision for that bug. If a bug needs to be fixed, add tasks for fixing bugs to your plan, regardless of whether they’re related to your current stories. These bug-fixing tasks are part of your overhead and they don’t contribute to calculating your capacity.

Some bugs will be too big to absorb into your current iteration. Create story cards for them and schedule them into your next iteration. Fixing bugs immediately will help reduce the number of bugs you face.

If you have a legacy codebase with a lot of bugs, go through your bug database and make a “fix” or “don’t fix” decision for your next release. Close or defer the “don’t fix” bugs and turn the remainder into stories.

All the tasks in our plan depend on code that other people are still working on. What should I do?

You can write code that depends on unfinished code. Talk to the people who have the other task and come to an agreement about module, class, and method names, then stub in the part they’re working on. The “Collective Code Ownership” practice has the details.

Prerequisites

Iterations and continuous flow both depend on small stories—about a day each, if the team works together. Larger stories make it easy for things to go wrong without being noticed.

Allies

Stories

Incremental Design

Capacity

Slack

Every story the team finishes should make progress that on-site customers can recognize—if not in production, then at least in a staging environment. This requires that stories be customer-centric and that technical infrastructure be built incrementally.

Consistently meeting iteration commitments requires basing your capacity on measured reality. Never artificially inflate your team’s capacity. Even then, things will go wrong, so your iteration must include slack to absorb those problems.

Never use commitment as a club. Don’t force team members to commit to a plan that they don’t agree with. Don’t disclose iteration commitments outside the team until you have a track record of meeting them.

Indicators

When you plan your tasks well:

• The whole team understands what needs to be done to finish its stories.

• The team works together to accomplish its plan.

• The team is aware of when things are going well and when they’re not, and takes action to correct problems.

When you use iterations well:

• Your team has a consistent, predictable capacity.

• Stakeholders know what to expect from the team and trust that it will deliver on its iteration commitments.

• The team discovers mistakes quickly and is usually able to deal with them without impacting its iteration commitments.

Alternatives and Experiments

The standout difference between Agile and non-Agile task planning is collective ownership. Not only are Agile teams in charge of their own planning, they also work together to finish their plan. On non-Agile teams, tasks are typically assigned by managers, and people focus on their individual tasks.

Another difference is Agile’s iterative and incremental nature. Small stories result in steady, incremental progress. Teams show that progress with working software every week or two. They use that software to get feedback, which in turn causes them to iterate their plans.

As you think about ways of experimenting with task planning, be sure to keep those core differences in mind. Don’t be too eager to experiment, though: there are a lot of subtleties to task planning, particularly iterations, so focus on getting really good at making and meeting one-week iteration commitments before trying alternatives. Give it several months, at least.

When you’re ready to experiment, one obvious experiment is to try continuous flow rather than iterations. You can also experiment with iteration length and story size. Some teams prefer to use very small stories that take only a few hours to complete. For these teams, tasks aren’t necessary. The stories are so small, they act as tasks on their own.

One area where you can start experimenting right away is your task board visualization. As a visual representation of your team’s process, it can and should change any time you have ideas for improving your process.

One common task visualization is to create vertical “swim lanes” that show stories’ progress through various phases of development. I prefer to avoid this approach myself, because Agile works best when you work on all “phases” simultaneously—but, admittedly, that depends on Delivering practices. For teams who aren’t pursuing Delivering fluency, a swim-lane diagram can be helpful.

Further Reading

Agile Estimating and Planning [Cohn2005] and Planning Extreme Programming [Beck2000b] each provide alternative ways of approaching iteration planning.

Continuous flow is often called “Kanban.” However, there’s much more to Kanban than just continuous flow. Kanban [Anderson2010] is a good way to learn more.