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.

Sign up for GitHub

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

Draft of process description #12

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Draft of process description #12

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions conventions/process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Process

## Prioritisation

Unless specifically raised the normal order of priority is:
* The board of your product team comes before the component board.
* The right-hand of the board comes before the left-hand side of the board.

## I just finished a task, what do I do next
Before starting a brand new task first help old task to be finished.
Following the priority order check:

### You product team board

1) There is any task that you implemented that needs your attention (eg: update with the latest master, update the staging machine).

2) There is any task that needs code review?

### React board

3) repeat 1 for the React board.
4) repeat 2 for the React board.

### Pick a new task

5) Check the task in TODO for your product team board, from top to bottom pick the first unassigned.

If there are **no unassigned** task in TODO in your product team board ask:

* Other developers in your team if you can pick some task assigned to them.
* The product manager of your team if some task on top of the backlog is ready to be worked with.
* The Frontend Tech Lead (this is your last resource).


## Picking up a new task

(aka The three amigos meeting)

When picking up a new task first thing to do is to verify that you have everything to work with that task.

Copy link
Contributor

@rlengvenis rlengvenis Jun 28, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say this step should be done before estimations. Imagine a case, we agreed to complete X tasks during a sprint. When a person starts to work on a task, he suddenly finds out, that backend is not ready, or some other stuff is missing, than needs additional time. Thats were we finish with < 2 tasks done a week.

The way I see it. Everyone should spend 20 mins before sprint planning to get accustomed with tasks and see if there are any inconsistencies (BE from BE perspective, FE from EF and etc).

Then, during sprint planning we will be able to address these things and can use free amigos approach to deal with all issues before doing estimations what tasks will be done during next sprint.

The way we did in my previous job is that we split tasks between team members and did 20min reviews each taking to look to 3/2 tasks. So no need to you Marco to look at all tasks by yourself

Without 20min reviews we are having meetings, where noone knows deeply all the context around the ticket and a lot of issues are missed during estimation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To address the size of the ticket we have the backlog grooming session (aka preplanning).

If you discuss every ticket in details during planning/preplanning you will have constantly half of the team idle during the meeting, since only a few people work at each ticket.

Three amigos can be done between preplanning and planning. But when you pick it up you should verify that everything is clear to all the people involved.

Also that is the complete list of checks, hopefully, a good part should already be covered during the meetings, so when you pick the card there is very little to do.

In general, I think that the main point is what to do, and what is the deadline to do it (before start writing code). If you want to do that slightly differently and before is completely up to the implementer.

Read the Jira card carefully, if some field is missing or is badly written ask the right person how to fix it. If the card has not been sufficiently discussed in a team meeting involve the people that needs to be involved (no more no less).

* Ask the product manager for a description of the functionality
* Ask the designer for the latest design and all the assets that you may need.
* Verify with QA how this task is going to be tested.
* If the task needs some back-end support to ask a backend developer.

The benefit of this phase is:

* Builds a shared understanding about the intent of an increment of work.
* Identifies misunderstandings and confusion early and allows learning to happen sooner in the delivery of an increment of work.
* Provides a reasonable guard rail for the number of people who should be involved in discussions about any given increment of work.