Guide: Sprint Planning with the Task Design Board

When attending planning sessions, I often realize that teams are stumped about the idea, "What is a meaningful task?" They come up with the standard tasks, "It needs to be developed, tested, deployed" - well, that's true. Yet, it's not very value adding. And it makes the planning meeting quite boring.
Here is a suggestion how you could approach task extraction in a way that adds a significant amount of value - and fun.

An example Task Design Board

The task design board

Let's check out what a "task design board" is: Instead of hudding around a meeting table and looking at a projector, developers make their work visual. They draw a design model representing their area of work - in our case, the architecture. Then, they add task cards in places where they intend to do work, denoting what they want to change. 

Step 1: Create a model

As we discussed above, in our case, we created an architecture model. Depending on what your backlog items are, you may also look into causal-loop diagrams, entity-relationship models, flowcharts or whatever floats your boat (pun intended). The model doesn't matter - as long as everyone understands why the model is useful and agrees that the model adequately displays the problem which the team is working on.

It's important that people understand the difference between "what is" and "what will be", because that is where the work-to-do comes in. In some cases, "what we still need to explore" is also a valid option. A suggestion may be to use different colored pens or small icons to denote these differences. 

Step 2: Defining tasks

After we know where we need to do some work, we add tasks which define what work we intend to do in order to move "from here to there", i.e. to the desired future state that solves the problem at hand. In the first draft, tasks can be very crude, such as "Website" - which is enough to indicate that there's work to be done.

Step 3: Refine tasks

This step is completely optional in a cross-functional team with close collaboration. If the team consists of specialists with limited interaction points, some tasks may need to be refined in order to be "workable". Let's take our example "Website". Maybe we need to break that down into "Set up webserver", "Create HTML", "Create CSS". The key in task refinement is not to have microslices of work as much as creating task slices that can be delivered without causing handovers delays in the process. The level at which you slice is defined by the team's skill distribution.

Step 4: Slice tasks

This is yet another optional task, depending on how quickly the team delivers. To decrease the risk and impact of blockages, tasks should not take more than 1-2 days. If the team has discovered that some task cards they created are probably significantly larger than 2 days, it may be a good idea to slice them down even further using techniques such as FURPS+, Impact Mapping or Specification by Example.

Step 5: Reduce tasks

You've probably run wild creating 100 tasks for a single Sprint now. Congratulations! That was fun. Now, we need to get pragmatic: Which of these tasks are really needed - and how many of them can we even do in a Sprint? Keep value and simplicity in mind. Your most important tool in this step is the trashbin, where all tasks go that have been created in a design frenzy. 

Step 6 - Order tasks

After you know what you really want to do, put tasks into a sensible order. A few constraints in ordering will go a long way.

1 - Cluster around value: Put tasks together that result in deliverable, visible customer value.

2 - Arrange by value: Start with the clusters that deliver the highest customer value.

3 - Arrange by feasibility: Inside the cluster, first do the tasks that could be done right now, i.e. that don't have unmet prerequisites.

Step 7: Assign tasks

This step is highly arguable. I personally don't recommend doing this in Planning already - yet some teams find value in this. Take a look at the task cards and ask around who will do what. 

Task assignment needs a few rules to work out properly:

1 - Pull: People take tasks. Nobody is allowed to "give" a task to anyone. 

2 - Consider Capacity: Nobody should take more tasks than they are confident they can handle.

3 - Think team: Look for ways to collaborate and do tasks together in order to proceed faster.

Step 8: Confidence vote

To conclude, let everyone take a step back and take a look at the created Sprint Plan. 

Does anyone see some unfeasible tasks? Is someone overburdened? Have we missed something? 

Everyone raise their hands in a display of confidence: Can we do this?

5 fingers = Yes!!!

3 finger = I have some concerns.

0 fingers = No way.

Numbers inbetween are ok.

If we get less than 4 fingers from most team members, we should discuss and resolve the problem.

Summary

Are you fed up with boring projector shows and ineffective planning sessions?

Try the Task Design Board as a simple, effective and energetic tool to run a Sprint Planning on low-tech, tipping deeply into the brains of developers to come up with a feasible, exciting plan.