Assigning work

 When assigning work to team members, there are multiple considerations:

•     Training developers on unfamiliar code
•     Ensuring each developer has work to do
•     Ease of planning what should go into a sprint/PI
•     How quickly an issue can be done by the developers that could do it
•     Context sharing with other developers who will work on a feature/epic
•     How detailed the design needs to be
•     How hard it is to estimate

How affects:

•     Confidence on when feature will be complete
•     Training team members on code bases
•     Time to approve changes
•     Speed of development
•     Likelihood of unplanned work
•     Likelihood of work being completed in expected time frame (all needed scenarios, not causing problems)
•     How uniform and easy to understand the code base is
•     How sprint burn down charts look
•     How many sprints are required to complete blocker chains

Code Review Suggestions

Goal: identity significant problems so they can be fixed before deployment.


Ensure the code is:

•     Bug free (for bugs with a significant chance of happening)
•     Generally meets the goals of the change
•     Has appropriate automated testing
•     Doesn’t cause unexpected problems
•     Doesn’t decrease security, scalability, robustness, etc
•     Maintainable and understandable by future developers
•     Generally solves problems using similar techniques as the rest of the code in the repository.
•     No unreasonable risks
•     Answers important “why” questions. Code inspection often easily answers “What” but look for important unanswered “Why” questions
  

Reviewers aren’t expected to:

•     Find all bugs
•     Enforce style (formatting, way of doing things, etc) as long as it fits reasonably with the rest of the codebase

Suggestions:

It is good to make optional suggestions as long as it is clear that they are optional and don’t affect approval.