Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update repo to include Github Projects #110

Open
iteles opened this issue Dec 3, 2018 · 1 comment
Open

Update repo to include Github Projects #110

iteles opened this issue Dec 3, 2018 · 1 comment
Labels

Comments

@iteles
Copy link
Member

iteles commented Dec 3, 2018

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

  • Ideate: Define User Story
  • Create UX/UI Wireframe/flow
  • Tech Spec (add checklist)
  • Estimate Time
  • Ready for Dev
  • In Development
  • Ready for Review
  • In Review (Pull Request)
  • Ready for Test
  • In Test
  • Ready for Signoff (Business)
  • Done 🚀

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

  • Dependencies/Open Questions
  • Project backlog
  • Sprint backlog
  • In progress
  • Awaiting review
  • Awaiting testing
  • Done

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:

  • Ideate: Define User Story / Project Backlog
  • Create UX/UI Wireframe/flow
  • Ready for Tech Spec (this is not something we currently add to anything other than very complex issues, we may need to provide some good examples)
  • Estimate time
  • Sprint backlog (things can only be moved here once they are time estimated)
    • Alternatively we use milestones only to demarcate sprint and this becomes the prioritised project back
  • In Development Progress (these can sometimes be questions
  • Ready for Awaiting Review
  • In Review (Pull Request)
    • We trialled this column in the CI project and it was never used, but my hypothesis is that this was because QAs don't go through the Projects, they look at what is assigned to them only - if adding the in-review label automagically moved the issue into this column, then we could keep the column
  • Ready for Test
  • In Test - Even our best POs have not in the past moved any issues in the Project. Unless there is a dedicated Tester, I would vote that we remove this column for simplification - the issue is either awaiting test, has a bug or a question or is 'done'
  • Ready for Signoff (Business) - I would also suggest we remove this column as for now, the vast majority of our issues go from Awaiting Testing to Done as the PO/tester also provides sign off
  • Done 🚀

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
Copy link
Member

nelsonic commented Dec 6, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants