You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
In #109, @nelsonic proposed the following columns:
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:
DevelopmentProgress (these can sometimes be questionsReady forAwaiting Reviewin-review
label automagically moved the issue into this column, then we could keep the columnIn 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 fromAwaiting Testing
toDone
as the PO/tester also provides sign offI 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.
The text was updated successfully, but these errors were encountered: