Task Board (Sprintboard) Basics and Philosophy

Note: this was originally written for a single Wikimedia team and a small audience, with a lot of sourcing from all over the internet, so it's likely lifted entire phrases or sentences without precise attribution. If you notice anything that should be precisely cited with a known source, please feel free to do so. It is posted here because it has often been shared privately and the info is useful to have in a public space.

2017-09-01

Obligatory TL;DR:

The scope of "what is the sprintboard for" is interdependent with other process things like "who owns the backlog" and "what is X person's role," so it's something that can take us a lot of different directions. Most simply put, a task board is an information radiator, and shows what you have committed to, what you are doing, who is doing what, etc, to the team as well as outsiders to the team. It does not necessarily show why you are doing something, or how, but in many versions does.

I've tried to limit this email to the board's "traditional" purpose, some different philosophies, as well as what I observe with this team. This is by no means an exhaustive descriptor. Exhausting maybe, but I'll let you decide. :)

The black list-items are subjects, the sub list-items are sorta sectional TL;DRs, and anything deeper is detail. Godspeed, readers.

What a task board is traditionally for

• • It’s a place where you can visualize the scope of your current work, your focus. That means it is also a place where there is a narrative about the work, and you don't have to read your email or even leave your to-do list, to hear that narrative. It’s generally easier to do that in a place separate from the pile of future work (the backlog).
    • Usually, this includes the team members with whom you collaborate.
    • Your work can include
      • Stories
      • Tasks
      • Features
      • Bugs
      • Tests
      • Research
      • etc
    • The task board focuses on "state" while the backlog focuses on "type" or "category" or "priority" etc.
      • The idea is that once a task is on the task board (and out of the backlog), it's relevance is inherent, and it's about "how do we get this finished" and not "why are we doing this, and in this order."
        • You can be granular with ordering in the task board, but it's nuanced and I dunno that there is a standard beyond "top thing first."
      • This obviously relies on the backlog being in good enough shape.
  • Some good guidelines:
    • The board is a mirror of the team's process, work, discussion, etc, aside from that which typically happens on a backlog instead
      • The board should represent the team's process of work.
      • The board should clarify what information the team wants to transmit.
      • The board should be built and used collectively.
    • If a board isn't working for a team, it's worth considering if that the team is doing is actually what isn't working.

What a task board normally looks like

• • "To Do" and "Done" are the old-school columns.
    • "In Progress" is a commonly cited 3rd, intermediary column, but technically it's not necessary. Sorta like, "if you have A, you must have B, but not necessarily C."
      • Regardless, most teams traditionally adapt the board to the process components they want to call out (including "Testing" or "Needs Review" or "Blocked" etc). What do we have to do? What is impeding us from doing it? What level of granularity is required to clarify efficiently?
  • Sometimes there are rows in addition to columns (rather than one row and several columns). Phab can't really do that, but for the sake of completeness...
    • You could have a row each for stories.
    • You could have a row for expedited needs ("Urgent").
  • The board is often updated once daily, when the team meets, but can also be continuously updated as long as doing so benefits others.
• What task boards tell us, and how they are useful
  • The task board is another buffer in the whole “plan and execute work” process, facilitating conversation around the state of work and impediments.
    • For example, it might become clear that a task needs tests before it can be completed, so there might be a column for that.
    • Or a team might have expectations about how fast work should be done (iterations in Scrum, WIP in Kanban), and the task board surfaces the state of work (a card is lingering, perhaps).
    • Maybe the team wants to do something new, and the board tells them, at a glance, if that is possible.
  • In our world, the sprint board is advertising. It’s a progress bar to higherups, a point of pride to peers, and a recruiting tool for outsiders.
  • An central principle in Scrum and Kanban is transparency. A board of the state of tasks helps with that. What is everyone else working on? What progress is being made? What is the team trying to accomplish?
  • If it's not already clear, the task board is an information radiator.
    • It serves as a focal point for conversation, including standup, making sure the focus is on progress and obstacles.
    • What have we committed to?
    • What's done?
    • What are we currently working on?
    • Are we working on the right things?
    • Are we working together (perhaps noted by assignees)?
    • What's blocked?
    • How much work is interrupting or urgent?
    • What the hell should I work on next?

How a scrum task board and a kanban task board are different

• • They are basically the same, with slight philosophical and practical variations.
    • Scrum boards are designed with sprints and deadlines in mind, so the guidelines around using the board focus on limiting work scope for a batch or iteration.
      • Everyone on a Scrum team is responsible for everything on the board.
      • Scrum limits WIP per iteration, so it's OK to work on everything at once.
      • Sprint boards are consistent and repeatable, short enough to focus the work and long enough to ship something.
      • An often-cited analogy is that Scrum boards are like a school test: complete a set of tasks in a time limit, and nothing else is allowed.
    • Kanban boards are designed with continuous flow in mind, so the guidelines around using the board focus on limiting WIP continuously.
      • Kanban teams are all about bottlenecks: while everyone has their specialty (coder, tester, etc), and can choose what to work on and how, the Kanban board suffers if there are bottlenecks. That is, you can't work on everything at once, because there isn't another limiter to save you.
      • You want enough work to be avoid idling, and not so much that you are stretched thin, or doing unworthy work.
      • Unstarted work can freely enter or exit the board (so can started work, though that is rarer because it is more expensive).
      • An often-cited analogy is that Kanban boards are like a basketball game, where each task is a scoring point and you want to minimize time between your team's scoring, including if you come up with a new play you want to try out.
  • Kanban allows you to change your mind more, but wants you to focus on less at a time.
  • Scrum says, “don’t change anything unless it’s planning time” so that you can focus and avoid the pitfalls of changing your mind all the time (or having your focus changed for you).

Who traditionally "owns" the task board

• • In a world where the backlog is the domain of the Product Owner (or whomever sets the priorities and does triage), the task board is the domain of the people executing the tasks. This is the Scrum approach.
  • In a world where work is more fluid, the backlog remains the area of expertise for the person who sets priorities, and as a tradeoff it's more kosher that the person primarily setting the priorities has some say in the style and approach of the task board. This is more like Kanban.
  • In my ideal scenario, everyone has a say if they feel they need to, and if there are unresolvable conflicting ideas, then my default are the Scrum guidelines for ownership, because I think it's simplest.

How task boards are limited, and pitfalls

• • A task board can't show you why someone's capacity is limited (say, because they are doing code review for another team)...
    • ...unless you list why on the board...
      • and doing that can risk corrupting more relevant information on the board.
      • I prefer to only put relevant work on the board, and have conversations about limited capacity
        • You wouldn't, for example, add a task that says "Stephen on vacation", so you probably shouldn't add a task that says "Stephen doing code review for another team"; his limited capacity is reflected in conversation and the fact that he is not picking up team tasks.
          • On the other hand, if it's isn't on the board then it's a secret to anyone who just gets their info from the board, such as Wikimedia volunteers.
  • A task board gives you a high-level picture, but it doesn't show you the conversations, just narratives
    • The tasks themselves (at best) show the conversations, and unless you have a physical board then you have to click deeper into another mode (card-view).
  • Scrum boards limit batches purposefully, but can be onerous when you want to change work quickly.
    • That's by design, but if you are an interrupt-driven team, or your ability to meet together is limited (Web suffers both to some degree), even 1-week sprints don't offer enough flexibility.
  • Similarly, Kanban boards offer so much flexibility that, without process maturity, a team risk issues, such as...
    • ...information silos,
    • over-specialization of team members, and
    • "throwing things over the wall" to the "next" person, as well as
    • simply regressing to a linear, Waterfall approach to work.
  • Both Scrum and Kanban are successful ways to manage workflows because of the limits they impose, but those limits can be manipulated.
    • It's up to a team to decide if they are doing so to enable dysfunction, or if they are actually adapting to a unique thing in their process (for example, communicating with the wiki community).
  • Too much information.
    • Much like my enormous emails on process (the irony is not lost on me, but I don't have time for fancy Nirzar slide decks even though I have a fancy art degree), if there is too much information to digest on the board (or the information isn't accessible independent of other noise) then the board becomes less useful.
      • "Information radiator" is great. "Information house-on-fire" is less great.
    • Alternatively, if a board is typically a good board, but is currently a mess, that might indicate a current mess with the team, and the board is doing its job. It's up to the team to decide what makes the board good, but this writeup includes a handy set of guidelines towards the beginning. ;)
  • Ask yourself: Is your board for the TEAM'S benefit, or for the PROJECT'S benefit?
    • The answer will likely influence how you design your board and norms around it.
    • I'm genuinely curious what the team thinks, I dunno that I could answer this for you.

How task boards are limited by Phab

• • Often you’ll see a “Story” column (https://agiletools.files.wordpress.com/2007/11/simpletasks.gif?w=450) that guides the task rows for tasks actually being done, and clarifies quickly why they are being done. Phab can't do that, nor generally anything with more than one row.
  • Phab isn't as flexible as a post-it that you can re-orient to mean different things (sideways cards, for instance), or add "requests" directly to a card ("Please test this" sticky on top of another sticky).
    • Adding features to a stickynote wall is a lot easier than requesting upstream to the Phab Gods (although you could argue that the latter could result in a more open-source, info-sharing product).
  • You can only assign one person.
    • Pair programming, anyone?

How task boards are enhanced by Phab

• • Phab is electronic data.
    • That data can be plugged into things like Phlogiston for reports.
  • Phab can also integrate...
    • ...with tools like git and gerrit for automatic information updating, as well as allow one task to be represented in several different places for better cross-team coordination.
  • As implied above, Phab can categorize things for you.
  • It's probably easier to have a conversation on a Phab card than it is on a post-it, especially for a remote team.
    • Even if in-person or face-to-face is easier for talking, having a centralized written record is bueno.
  • Notifications!
    • Though with Phab this is debatable. :-D

I hope that helps clarify what sprint/kanban/task boards are for. At the very least, I hope it supports the right mindset as you think about what you want your board to do for you. I want the team to be asking questions like, “Is X valuable to have on the board? For the project? For me? For others? What does adding X to the board cost?” Norms and restrictions on the board are great, if not necessary, but a truly mature team asks the questions that the norms try to preemptively answer. The norms should serve you, not the other way around.

I borrowed some language, ideas, and occasionally whole sentences from:

• https://realtimeboard.com/blog/scrum-kanban-boards-differences/
• https://www.agilealliance.org/glossary/kanban-board/
• https://agiletools.wordpress.com/2007/11/24/task-boards-telling-a-compelling-agile-story/
• http://agileforall.com/building-a-useful-task-board/
• http://www.xqa.com.ar/visualmanagement/
• http://agilefeedback.blogspot.fr/2012/04/how-we-built-our-taskboard.html
• https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards