2/ We copy our feature list template into the specific project and begin editing it. I'll share what's in the template.
3/ We start with the "global" task (the one that says "🌎NAME OF FEATURE."
The first section of that template task is for PMs. It's a checklist of sorts to help us know what we need to complete before a dev can start.
4/ Item #3 in the list is where the PM shares (1) all they know about the context, (2) resources/assets, and (3) an answer to "how do we know this work is done?"
5/ Here's an example of a context note for a real project we are working on this week. Providing this context allows the dev to be creative in how they code the thing, and possibly propose risks and alternatives.
6/ In the global task, we also have sections for "Feature Implementation and Design Notes" and "The Client's Definition of Done" (DOD).
The client's DOD is always a good challenge to put in writing. It basically answers, "How will we all know this feature is really done?"
7/ The last part lists the dev's duties. Just like the PM duties, it serves as a reminder of how to approach the work. It becomes muscle memory after a few assignments.
8/ Once the details of the feature have been captured in the global task, we communicate the assignment to the dev in an event document we call the "Plan of Action." The POA doc is also where we hold an async retrospective after the work is done.
9/ We create a unique POA + Retro event doc for each project we are scheduled to work on for the week. Our weeks are Thursday to Wednesday. The PM and devs are the only ones assigned to prevent cluttering the notifications of team members.
10/ On Thursday, the start of the week, every dev is given 1-2 POAs to work. They take up to 2 hours to review the assignments and communicate back a few important details for the PM.
11/ Here's what each dev does every week when starting a new POA.
12/ In each task, they answer 4 'scope' questions for the PM and client to see. 1. Any process red flags? 2. What's your estimate to complete, do QA and deploy? 3. What can we remove or split out to make this take less 4 hours? 4. What could make this go longer than estimated?
13/ Finally, they comment on the POA answering these questions. Based on the answers, the PM can dive into action to resolve issues or carry on with other work.
14/ If there are no blockers or issues, the dev can also carry on simply checking in each day via async comments on their status. The hope is they can work mostly uninterrupted all week and unblocked.
15/ That's how we keep a calm-for-everyone pace of assigning feature work to devs in an async, global team.
One of my culture goals at @fostercommerce is for it to be a calm company where the team can do deep work w/ few interruptions and be a team willing to be interrupted to help. I think we found our groove by categorizing time commitments into two groups: Primary and "+5"
Primary time is the core commitment of the job. At best, and often, it is spent on one project for the whole week. The work is defined for the engineer so they can do a full review on Monday to catch any last minute red flags before diving in for the week. There are no meetings.
Primary time is typically marked by 25 billable hours/week. This number varies for each engineer. Essentially, the engineer agrees to give a solid 25 hours of deep work toward the defined scope of work for their "weekly primary project." Once you've hit the hours, you're done.