PM/PO to Define Workflow in dwyl App Project

[nelsonic]

At present the project https:/dwyl/app/projects/1 has the default GitHub Kanban workflow:

• Todo
• In progress
• Review in progress
• Reviewer approved
• Done

This is not the workflow we are used to.
We usually have more steps that aid communication in the team.
e.g: Todo could be the default column where all new issues are added upon creation,
but we need a way to indicate that an issue has been "triaged" (filtered/prioritised) by the PM/PO.
It could be that only issues that have been reviewed by the PM/PO are put into the Todo and that everything else is awaiting triage (and therefore should not be considered "Todo").
But this needs to be explicit so there's no confusion. We've had projects in the past were time has been wasted due to uncertainty about what needs to be done next or what doesn't need to be done at all.

We can evolve our workflow over time, we just need to have something clear for the first couple of sprints.

Related to dwyl/contributing#109 (Consolidate GitHub Workflow)
Though I don't think we need 12 columns as that is probably overkill in a team of 3 people ... 🙄

Acceptance Criteria

• Agree on starting point for GH project columns
• Implement project columns
• Document divergences from dwyl's standard workflow for this repo (with a view to updating it in the main repo asap EPIC: Consolidate our GitHub "Workflow" into *Single* Reference contributing#109)

[iteles]

From our standard set of columns, I propose that having the following columns would be beneficial to the dwyl app project:

• Backlog & Sprint X: Either one or both of these
  • We briefly discussed on our call this morning that @nelsonic, you have a preference to not have a sprint column, I'd like to hear more about why this is
  • To date, my personal experience of having both a backlog and a sprint X column is that the backlog column allows for good prioritisation of issues (with the auto-adding of new issues off) and having sprint column has been useful because it gives us a clear idea of how much still needs to be done for that sprint
    • I like to see it as 'what is happening now' and 'what is happening next', keeping both visible and above the fold (though you could argue this lacks focus)
  • I also like to have a differentiation where nothing makes it into the 'Sprint X' column until the full spec is written out, meaning we could do away with the 'tech spec' column
  • Having said this, now that we can move issues along the project from within the issue itself, it's possible that there will be less of a reason to look at the project directly. As such, it would be ok to use the sprint milestone to keep an eye on what still needs to be done rather than adding a column here - happy to try this out if this is your reasoning
• In progress/development
• Ready for Review
  • We have previously trialled having an 'In Review' column and it didn't get much use. I propose that for a team of 3 people, this is more transparently managed through labels rather than an additional column
• Ready for Testing
• Completed

Notes

• It's possible that after MVP we may well need a 'wireframes/UI' column, this should be added in in a couple of sprints when it makes sense
• I haven't added an 'Estimate' column because I don't intend to let anything get into the sprint milestone without an estimate
• Once we start testing with real people in a couple of weeks, I expect that the testing section of the columns will need to expand for clarity/organisation, but this will be iterated on at the time.

[nelsonic]

@iteles my reasoning for not having a Sprint X column is simple: it has to keep changing.
I'd much rather have a rule that we attempt to have a really good backlog of issues that have been "groomed" and estimated and if they are on the project board, they can be worked on.

I would much prefer to have many more stories ready for development (and estimated) in the Todo column and encourage people to follow the "Pull principle" whereby "tasks are not assigned to the team members by the team leader or project manager. Each team member chooses which task from the To Do section they are going to complete next. This guarantees a smooth process flow, where all the team members are equally busy at all times."

Agree with leaving auto-adding of issues off. 👍
Agree that seeing "what's happening now" is exactly what the point of the Project/Board is. 👍
The Project/Board should be the thing/page/view we open all standup calls with.

I'm keen to not change the names of any of the default (Github Kanban) columns to minimise the onboarding time for people who have seen a GitHub board before, but not the @dwyl one.
E.g: I don't see the advantage to changing Done to Completed.

Ready for Review and Ready for Testing make sense in terms of our product/dev workflow,
but could we name them the same as our existing labels awaiting-review and please-test ?

Agree with notes and the potential need for UI column ... for now, can we assume that an issue that has the UI/UX Label applied will only be estimated once the wireframe/interaction has been added to the issue description?
Agree with being strict with regards to estimation before allowing an issue into the sprint/milestone. 👍
Agree with having a focus on UX testing and possibly requiring a dedicated column for it. 💭

[iteles]

Thanks for your thoughts @nelsonic, agreed.
I have left the first column as To do but I'm not too keen on the concept of infinite to-do lists and have a personal preference for using 'Backlog' instead, but let's test this out.

With regards to your note on the sprint column & using the pull principle, I think it'll be a great thing to try out. Time estimation (both before work begins on an issue and after the issue is complete) will be of the essence as our keenest measure of cadence.

The only disadvantage that I can see here from a personal perspective is that there is no way for a PM to prioritise issues for their own review as only issues that have already been reviewed and deemed 'complete issues' can make it onto the board.

Note: New issues are not automatically added to the project but when a new issue is manually added to the project, it is automatically added to the bottom of the To do column (rather than hanging out in a 'triage' area. I have found this preferable from experience so that there aren't a number of issues constantly 'haunting' the triage area:

There is documentation to be written up here on things like only issues reviewed by the PM make it onto the To Do column. This will form part of dwyl/contributing#109

[iteles]

Remaining work is to write this up once we have tested the simplified flow for a little while.

Will be part of dwyl/contributing#109

[iteles]

I'm going to write up a contributing.md specific to this repo, referencing our wider one.

[nelsonic]

@iteles what remains to be done for this issue? (it's been in-progress for almost a month...) 💭
Can you please add a checklist to the top so we know when it's finished? ✅
See: https:/dwyl/app/milestone/3 ⏳
Thanks. ✨

[nelsonic]

Done: https:/dwyl/app/blob/master/contributing.md ✅