Chapter 4 of 8 · 4 checks · 2 min
Split work fairly
Fair work splits prevent resentment and make individual marking straightforward. Give each member clear ownership, track tasks visibly and share both code and writing.
Give each member ownership of whole components or featuresShould
Why it matters and how to check
Splitting by layer, such as one person on frontend, one on backend and one on documents, creates bottlenecks and makes it hard to see who built what. Splitting by feature or component, such as one person owning sync, another reports and alerts, another scanning and inventory, gives each member something they can build, test, demo and explain end to end.
Shared foundations like the database schema and authentication can be built together early. Check it is done: each member can name the features they own and present in the final demo.
Do
- Assign features or components, not only layers
- Build shared foundations together early
Avoid
- One member owning all the code and others only documents
Track every task on a shared board with an owner and a due dateMust
Why it matters and how to check
Use a simple board with columns such as To do, In progress, In review and Done. GitHub Projects works well because issues and pull requests link to it directly; Trello or a shared spreadsheet also work.
Every task has one owner and a due date. The board becomes the shared truth about who is doing what, and an early warning when someone's tasks stop moving. Check it is done: every active task on the board has exactly one owner and a due date.
Do
- Give every task one owner and a due date
- Link tasks to issues and pull requests where possible
Avoid
- Tasks assigned to "everyone"
Make sure every member both writes code and writes part of the reportMust
Why it matters and how to check
Panels often assess individuals on both the system and the documentation, and each member may be asked to explain code and design. A member who only wrote the report, or only wrote code, is exposed in one of those areas.
Give each member the report sections that describe their own features, such as their design decisions, implementation and testing, plus a share of the common chapters. Check it is done: each member has commits in the code repository and named sections in the report.
Do
- Assign report sections that match each member's features
- Share common chapters such as introduction and literature review
Avoid
- One member writing the whole report alone
Share or rotate unpopular tasksNice to have
Why it matters and how to check
Every project has tasks nobody wants: formatting the report, writing test cases, cleaning data, preparing slides, chasing signatures. If the same person always does them, resentment builds.
List these tasks early and share or rotate them. Check it is done: the board shows unpopular tasks spread across members over the last month.
Do
- List unpopular tasks early
- Rotate them across members
Avoid
- Leaving all admin work to the most conscientious member