A Heuristic for Task Work

My rule of thumb for Task work – and one I highly recommend Teams adopt as a part of their Team Working Agreement – is as follows: Every Team Member’s name appears on one and only one in-progress, unblocked Task at a time.

This rule does not preclude multiple Team Members from working on the same Task. It does preclude any Team Member from signing up for or attempting to work on more than one Task at time. And that’s the point. Single-item flow is the most effective, most efficient way known to develop a product.


This example (partial) task board shows the task heuristic in operation

The result of this simple rule is that no one is working on more than one Task at once, meaning no one is attempting to engage in multitasking. Another result of this simple rule is that Tasks not yet in progress are available, by virtue of the fact that they live in the To Do column on the Task Board, for any Team Member to work on, until one or more Team Members sign up for the Task. This simple visual cue helps the Team see what needs to be worked on and also helps drive cross-functional behavior on the Team by making it physically possible for anyone to sign up for any available Task.

Excerpt from The Agile Team Handbook, page 139.

All for now….


The Complexity Trap, Part 2 – The Simplicity Solution

I presented this topic at Mile High Agile 2012 under the title: Great Teams Keep It Simple.

“Simplicity–the art of maximizing the amount of work not done–is essential.”

Agile Manifesto Principles

The first part of this post examined the complexity trap agile teams frequently fall into. Underlying complexity in team and work structures are reflected in equally complex artifacts that teams and leaders adopt in an effort to understand the problems they are encountering. Unfortunately, complex artifacts including backlogs, burndowns, and task boards, only serve to perpetuate or even enhance the underlying dysfunctions.

The only effective way out of the complexity trap – in my experience – is to work deliberately to apply the Agile Manifesto Principle of simplicity quoted above. The use of simple artifacts provides feedback that allows teams, leaders, and organizations as a whole to identify complexity and address it appropriately.

Here are a few questions to ponder:

  • How could the simplest thing that could possibly work be the best solution?
  • What should information radiators tell us?
  • Are we likely to finish everything we committed to this Sprint?
  • Which stories are at risk?
  • How much WIP (Work in Progress)?
  • What do we need to do today – as a team?
  • How many blockers are there?
  • How can I help?
  • How can simple tools foster and enhance teamwork?

Let’s look at some examples of simple artifacts that answer these and other vital questions.

Single-dimensional Backlog

This backlog is a single-dimensional, force-ranked list of all the items you have thought of for the product, but are not yet being developed. If you are practicing Scrum, the Product Owner sets the order of the items, whether User Stories or whatever. There can only ever be one item at the top, one item in the second slot, and so forth all the way down. In keeping with the backlog iceberg metaphor, items are more detailed at the top, less detailed as one descends through the list. When continuously groomed, a simple backlog like this ensures that the most valuable, important items are always available for a team to pull in and work on at any given time.

Minimalist Task Board

In contrast to the complex, multi-state task board depicted in Part 1 of this post, this task board is the model of simplicity. It contains a column for planned User Stories. It contains a column for planned tasks as they are currently understood. It contains a column for tasks in progress. Anything in these three columns comes under the heading of “not done” – either planned or in progress, with both of these categories clearly and instantly visible, but equally clearly not done. The fourth column holds tasks in a new state – done. The fifth and final column is for accepted User Stories, that is, stories whose Acceptance Criteria are satisfied – these stories are done.

Notice what’s going on here. First there are really only two states reflected on this task board for any work item: not done and done. There are containers for planned work, mostly so that the team doesn’t forget the results of conversations held during planning. Tasks in progress are instantly visible. Since work in progress (WIP) is by definition waste, this task board helps everyone focus on limiting WIP. Completed tasks move to the Done column – these tasks meet the team’s definition of done and should not need to be revisited unless something out of the ordinary occurs. And finally, stories whose Acceptance Criteria the team has met – and in the Scrum world that the Product Owner has accepted – move to the Story Accepted column. These stories are done, finished, ready for customer/stakeholder review.

A minimalist task board like this one focuses the team on teamwork instead of individual work. Stories belong to no one team member, but to the team as a whole. Individuals, pairs, or groups may (and should) sign up for tasks, but the focus remains on pushing stories across the board, from top to bottom. The tasks take their proper place as a means to an end, and a highly malleable, flexible means at that.

A few additional rules that I recommend for using a minimalist task board effectively:

  • Each team member’s name appears on only one unblocked task in the In Progress column at a time. This rule does wonders for WIP and also helps the team focus on team goals rather than individual preferences or expertise.
  • Work the stories from top to bottom – tasks deliver no value, stories do, so focus on stories regardless of individual task preference or expertise. Every team member does whatever it takes to help the team achieve its goal.
  • The team’s definition of done must extend as close to “potentially shippable” as possible. Using a simple task board with the binary “not done-done” dichotomy of states pushes teams in this direction.

Simple, Effective Burndowns

Burndown charts are somewhat controversial these days, but I still like them, especially for new or struggling agile teams. As with most other practitioners, I don’t like task-hour burndowns for a whole variety of reasons that I won’t go into here. Again, new or struggling agile teams – in my experience – need to break out the relevant tasks to deliver stories effectively. The tasks themselves aren’t the key – the whole-team engagement and discussion is the vital aspect here. Whole-team ownership of every aspect of every story is what we’re getting at and tasks are a good lever.

Back to the burndown, we could simply burn down the raw number of tasks. I’m fine with that if the team is able to break tasks down into roughly equal chunks. Most new or struggling agile teams lack the experience needed to achieve this goal. Moreover, unless team members estimate the tasks, they don’t really even know how big the tasks are. So here’s a simple rule I generally recommend teams adopt: Estimate tasks in half-day/day increments. Any task larger than a day is on the block to be chopped down to size. It’s just another feedback loop I want teams to build into their work. It takes tremendous discipline to keep tasks small. Estimates provide feedback on task size, which empowers the team to take appropriate action when things get out of whack.

Now that you have tasks estimated in half-day/day sizes, simply burn down the total number of half-day increments: a half-day task counts 1, a full-day task counts 2. Add them up, plot a point, and you’re done! And don’t worry about precision. Half-day and day gradations are plenty good enough. Breaking tasks down further than this level of granularity is an exercise in false precision and begins to engage optimism bias. Think about it this way: over the course of a year and thousands of tasks, the estimates normalize around the median, which is all one can ask of an estimate.

Half-day/day task sizes also foster meaningful conversation and collaboration in the Daily Scrum (stand-up, or whatever you are calling it). Everyone can always talk about at least one task completed since the last meeting if tasks don’t exceed one day in duration.

Story Point Burndown

Stories deliver value. We want to know how we’re doing on that. So burn down Story Points to reflect and radiate value delivered as the team delivers accepted stories. Enough said.

Team Working Agreements
Finally, team agreements foster team growth and strength. Remember that these are team agreements, not exhortations posted by management! When coaching agile teams, I suggest agreements that I think would be helpful, but no one can force a team to adopt a team working agreement – it must be a consensus team commitment. Here are a few examples:

  • We agree to pair-program at least two hours during each day of every Sprint.
  • We agree that each of us will work on at least one task per Sprint, either paired or individually, that is outside our area of specialist knowledge.
  • We agree that collaboration and collective, consensus-based decisions always produce better results than individual, even expert, opinion.

Post the full set of team working agreements in the team room for all to see. Reflect upon the team agreements regularly and update the list as conditions change.

I hope you’ve found this a thought-provoking and useful discussion on the merits of simplicity and simple solutions. In our hyper-complex world, we tend to disregard simplicity as being simplistic. Nothing could be further from the truth. When you encounter a complex problem, reflect on the Agile Manifesto Principle that started this post and look for a simple solution!

All for now….


The Complexity Trap, Part 1

I presented this topic at Mile High Agile 2012 under the title: Great Teams Keep It Simple.

“Simplicity–the art of maximizing the amount of work not done–is essential.”

Agile Manifesto Principles

Agile teams and leaders tend to think of this principle in terms of reducing the complexity of the product being developed, from UI/UX flows to the back-end code. There is another area in which it is vital to focus on simplicity, however: the way we use various agile artifacts. Areas of complexity include:

  • Backlogs
  • Task boards
  • Burndowns
  • Individual “Velocities”
  • Utilization tracking/measurement

The most obvious way backlogs become complex is when they contain too many detailed stories. I have seen backlogs that contained thousands and tens-of-thousands of stories. Such backlogs are unworkable, unmanageable, and wasteful.

Another, less obvious but more insidious way backlogs become complex is when they are sliced along functional layers, rather than across those layers. Like a cake made of wood, stories written within functional layers make the Product Backlog rigid and impenetrable. Functionally layered backlogs are rife with irreconcilable dependencies and integration nightmares.

Task Boards
Task boards generally become complex in two dimensions: work states and team assignment. In the former case, the task board develops many columns, each depicting an intermediate state of doneness for tasks or even stories. In the latter case, the task board gets cut into sections, one for each team member, with tasks and even stories falling into individual team-member domains, often during Sprint Planning. In extreme cases, I’ve seen both of these dimensions of complexity expressed on the same task board.

The usual result of complex task boards is unfinished work at the end of the Sprint, as depicted below:

Sprint Burndowns
The Sprint Burndown is an element of transparency, showing the inner workings of the Sprint for all the world to see – and for the team to use as an input to daily decisions. Sprint Burndowns also frequently become so complex that they are essentially unreadable, as in the example that follows, which tracks, among other things, actual hours expended, an inherently damaging metric.

Tracking Individual Velocities
One of the most insidious artifacts I’ve seen in use is the tracking of individual “velocities” within a team, the implication being that stories are written in such a way that only one person works on any given story. The damage this type of metric inflicts on a team is incredible and often difficult or even impossible to repair.

Symptoms of Complexity

Some of the symptoms of complex work structures, as indicated by complex artifacts include:

  • People with nothing to do the last couple of days of each Sprint – usually “developers”
  • People with nothing to do until the last couple of days of each Sprint – usually “testers”
  • Gold-plated code
  • Poor quality code
  • Unfinished work most Sprints
  • “We’ll test later”
  • Internal team stovepipes that require hand offs
  • Morale and motivation problems
  • Lack of Teamwork

Complexity in agile artifacts creeps in, uninvited or intentionally, for a variety of reasons.

  • Lack of team cross-functionality
  • Lack of a dedicated team – resource pooling and matrixing people across teams
  • Artifacts of thinking – habit
  • Fear
  • Lack of trust, both within the team and between the team and the broader organization

I often find that complexity results from teams’ and organizations’ attempts to find ways to adapt agile to their existing project management and organizational assumptions. Agile is all about changing the way people and organizations work, to move beyond organizational structures and assumptions that arose to serve a different purpose and way of working. Clinging those structures and assumptions, long after they have ceased to be effective, is a major impediment to improvement at every level, from individual teams to the organization as a whole.

Next time, let’s look at the opposite of complexity – simplicity – and apply the Agile Manifesto principle that started us off in practice.

All for now….