dwyl / contributing

:clipboard: Guidelines & Workflow for people contributing to our project(s) on GitHub. Please :star: to confirm you've read & understood! :white_check_mark:
86 stars 9 forks source link

Update repo to include Github Projects #110

Open iteles opened 5 years ago

iteles commented 5 years ago

In #109, @nelsonic proposed the following columns: tcm-workflow-with-blockers

In practice we have been using a more simplified structure, essentially skipping the first 4 proposed columns above and starting from 'Ready for Dev':

Whilst this may seen simpler, in reality it means that more often than not, adding tech spec and time estimates just doesn't get done.

For internal dwyl projects and for our client projects, usually the PO is the final decision maker and provides sign off, so my only proposed modifications to this as a starting point would be:

I suggest we add a 'Dependencies/Open Questions' column to this list because it is useful for the dev team and POs to keep track of what's blocking work.

nelsonic commented 5 years ago

@iteles I'm not "precious" about the names of the columns in the workflow.

All I (deeply) care about is that we optimise our workflow for the biggest "constraint" in any project: Product owner and ("senior") developer time. It should always be immediately clear from glancing at the "board" who is working on what task/feature, how long they expect it to take, whether something in the project is "blocked" and requires someone's attention what everyone's next priority is once they have finished their current task.

I never want to hear anyone say: "I don't know what to work on next". Wasting anyone's time because the backlog is not prioritised is unacceptable.