Planning & Process

Remember, 5 hours of coding will save you 1 hour of research. :)

• Arkency book "Async remote"

Planning and Process

These planning and process guidelines are defined to help us work together, better, while allowing everyone to work on their own, at their own pace.

Planning

All tasks should be defined as atomic (aka the smallest atomic task that brings business value). These should typically be no more than 1 day of length. The rationale of this, is that 1) everyone completes at least 1 activity every day, and 2) things do not spiral out of control on relative weights, that's don't really matter. The additional side effect of this, is that there is no "70% done, boss" mentality. Everything is binary. It is done, or it is not.

Process

Step 1. Work is broken down into a set of user stories. A user story is the definition of some part of the application. In many cases, where the definition is well understood and known, the story might be the only definition of the task. The task itself is enough of a definition to reduce the cognitive load and enable action. But, in other cases, we might need wireframes, etc. The point is that the user stories should be enough that the person responsible for the task can simply get to work. These user stories should not require more than 1 day to complete.

Step 2. Work is prioritized into a queue, with the most important next task next. This prioritized queue provides for us a way that engineering and other department personnel can simply grab the next task off the queue and do the work when they complete their previous task (similar to a web server).

Work that is queued should be actively worked to minimize dependencies on tasks around it in the queue. So, you shouldn't queue task A1, A2, A3 together. Rather, it should abe A1, B2, C3, A2, B3, C4 etc.

Step 3. A person takes the NEXT task. Human nature is to pick the easiest task in the queue. Therefore, each person that is working that queue, should take the next task. Sometimes it will be easy, and you will be able to complete multiple tasks in 1 day. Sometimes, you pick the harder one, and it will take an entire day to complete. But, in all cases, you're getting to work on many different things.

Ticket Types

There are a number of different tasks types that will be defined in the system. They are:

• Atomic - A generic task, something to do. An executable job.

• Specification Task - Based on the work breakdown structure, a section may need additional definition. A task that defines this additional breakdown is called a "Specification" task, and should be labeled as such. The output or results from this task, is a breakdown of tasks into atomic size tasks.

• Split Task - Sometimes, when a developer gets a task, it will be larger than an atomic size. It's not a problem to have these, and it makes sense to have them. When you have a ticket that needs to be split.. you define the sub tasks that are required, add each of these tasks to the ticket system, and then work on the first task. The Split task then is labeled as a Split, and then closed, once it has been broken down into smaller tasks.

• Challenge Task - No one should assume the tasks are added with full knowledge of the system. If you receive a task from the queue that is doubtful or questionable, contact the author and ask for clarification about why that task is created, and what outcome it is intended to bring about. Sometimes, you'll get information that helps you move forward. Sometimes, you'll change the task and its assumptions. Once the challenge has been resolved, continue on with the task. Leave the challenge on the task, so we can track the % of the time this happens.

Prioritization

How do we prioritize which tasks in which order?

• Defer technical decisions until the last possible moment. Maybe the task doesn't need to be created yet.

• Gather data about a task before defining it--create a task that creates the data, or a task that defines the behavior and use of the part, before doing the additional work to make it function.

• Detect the actors early - Who is going to use the data? How? Build with a prioritization to these actors.

• Prioritize unknowns - try to work through the unknowns of the system, and clear these unknowns. Once the unknowns are handled, the risk reduces significantly.

• All things being equal, Specification tasks have a priority over Atomic Tasks

Guidelines

• If you're out of sync, you don't understand the tickets and their priority, schedule a realtime meeting to go through the tickets, and make sure everyone understands what we are doing.