search

fru-io / handbook

How we work at DDEV
https://handbook.ddev.com
Creative Commons Attribution 4.0 International
10 stars 13 forks source link

Update scrum.md #51

Closed dclear closed 4 years ago

dclear commented 4 years ago

Open up a PR for team to comment on. Will review this in retro tomorrow.

nic-hima commented 4 years ago

Was there supposed to be more than just a 1 word edit?

dclear commented 4 years ago

Was there supposed to be more than just a 1 word edit?

No, the edit was an excuse to open up https://github.com/drud/community/blob/bf21846339e5d2d3f8ec3ea9f16e2e4fc48c2f9e/docs/project-management/scrum.md for discussion

nic-hima commented 4 years ago

Criticism to current options to provide feedback: I can't seem to find an easy way to comment on any line of this document... only within +/- 3 lines from the 1 line change made.

There is a typo line 41. The time should be 9:30 - 9:45 not 9:00 - 9:15.

Are we going to flag those kinds of technical breakout discussions for separate "rooms" and keep this breakout time more engineer/product/business cross discussion focused?

Overall though I present these questions to promote discussion and am going to keep my approval. Please fix typo

dclear commented 4 years ago

There is a typo line 41. The time should be 9:30 - 9:45 not 9:00 - 9:15.

Fixed, thx.

breakout a time when a product question can be asked by engineers? Or should those need to be put into GH first, and "presented" there?

Standup is timeboxed to the first 15, breakout is for the second fifteen+. Product / project management will join for that part on the engineering standup. To optimize time, whoever is calling for the breakout should share the related issue they are working against. If we run out of time, we can extend the breakout or arrange for another follow-up meeting.

It is a good practice to flag any blockers or breakouts where we are tracking work - in the GH issue. @ the relevant people to give them a headsup about what you want to discuss, whenever possible.

I also have some issues with the line because it does not take into account the potential for purely technical breakouts. Sometimes a question doesn't yet have an issue attached to it yet either.

Technical breakouts don't bypass a business requirement to document discussions, blockers, progress in Github, where our issues, sprints, and code reside. A breakout should be relevant to multiple folks and to work either planned or active. It's fine if there's a need to spin up a new issue. Just add a note on a related issue that a new ticket needs to be created, and do that after breakout. Or do a quick stub.

Try to be respectful of others' time when calling for a breakout. If it's an issue that you can work through with just 1 other person, then it probably doesn't need to be part of the team meeting. Use your best judgement.

Should we have a similar business rule that if a breakout is flagged as technical it is followed up on afterwards separately? Any decisions, questions for product, ideas, recorded in a relevant issue / PR, etc?

A breakout is a breakout -- any decisions need to be documented for visibility on the relevant issue. There's no differentiation between technical or non-technical in that regard. If you are blocked by a product decision, note it and @ / ping. I will be bringing these types of blockers to the business standup as well to help with turnaround.

Are we going to flag those kinds of technical breakout discussions for separate "rooms" and keep this breakout time more engineer/product/business cross discussion focused?

Not exactly sure what you mean here but I am fairly confident the answer is no. The engineers can and should use their breakout to get as technical as they want. It's a breakout for engineers. It's up to others to decide if they want to stay and listen in.