SPUDSCOP: Task communication framework

Over at Lifebit, we really care about productivity.  Shiki uses the Pomodoro technique, some teammates work in flexible hours, some work at home, while the rest of team in the HQ works on a compressed time range that allows a more concentrated focus. Part of my job as Chief “Everything else” officer is to pinpoint bottlenecks and trouble spots in terms of the overall productivity of the team.

We recently did a survey of the team on what the management can improve and it seems that one of the major productivity drain is the lack of clarity about a feature or a task. We use a fairly rapid non-style of just describing what needs to be done, writing whatever in the description and attaching mockups if any. Now, I have worked with Agile methodologies and one thing is for sure – I really hate how verbose and time consuming it is for both sides. Writing it is a huge chore and on the other side, the brain just falls off the rails before one can finish reading the story title (As a user, I want to be able….. zzzzz… zzzzzzzzz). So starting next year as a team we will try something more concise but still very descriptive.

It is basically Story + Person + Urgency + Description + States ///// Comprehension + Optimistic ETA + Pessimistic ETA. So I am calling it SPUDSCOP!

There are two parts to SPUDSCOP: the TASK CARD and the TASK RESPONSE.

TASK CARD (done by the project manager)

  1. Story Title: A simple task title that should contain the feature name and where its going to be located (page/page format).
  2. Person:  A short two words to indicate who will use it.
  3. Urgency: 3 urgency levels to guide teammates or managers.
    • critical – means the task needs to be started right away (drop other task) and teammates should not disturb doer until the task is done. Used this for critical bugs or key features needed for an event (presentation, meetups demos). A teammate that
    • Regular – finish the task at a normal pace (hopefully with no slack)
    • Low – work on this when you have nothing else to work on.
  4. Description: this is where you need to state how the feature works with a rationale on why this feature is in the product.
  5. Steps & states: How the feature looks in its different state or when relevant all the steps involved in the feature.

TASK RESPONSE (done by the developer or builder)

  1. Comprehension: shows the level of understanding of the builder after reading the description.
    • Need clarification – when the builder states this, the task creator should consider contacting the builder to start a conversation.
    • I think I got it – when the builder states this, the task creator should review their card to rewrod or clarify or fill out missing details
    • OK – the builder fully understands the task so the task card is already fine.
  2. Optimistic estimate: The builder should indicate a best estimate of WHEN the task will be completed. It is important to state the fastest possible time here.
  3. Pessimistic estimate: The builder should indicate an estimate of WHEN the task will be completed if there will be problems or stuckups.

We use Trello so here is an example of an actual task:

Trello-SPUDSCOP

Admittedly this framework is very suited for a project like Lifebit which is a platform with a big API in the middle, an iOS app, an Android app and a web app interfacing with the userbase. BUT I would imagine it will also work in any software project.

We will be using this framework moving forward and update this post on how it goes. Let us all hope for some productivity boost with SPUDSCOP!