Skip to content

Sprint 2 Feedback #39

Description

@mlinderm

Key: Exceeds Expectations (EE), Meets Expectations (ME), Below Expectations (BE), Falls short of expectations (FS)

User stories: ME (clear user stories, some over-constrained)
Agility: ME/EE (use of the backlog, assigned tasks, some commits throughout)
Integration: BE (self merges, broken builds)
Implementation: ME/EE (some tests, PropTypes, organized, with relational model)
Functionality: ME (good progress)

  • User stories are much improved! The feature and motivations are much more clear. Not all tasks need to or should fit the Connextra format, i.e., having a stakeholder. And specifically the developer as stakeholder doesn't make much sense. Infrastructure tasks are a means to achieve your actual features and can be expressed as such. While at some level that might seem like semantics, by connecting all the work, even infrastructure work, to the relevant features you can more clearly prioritize (e.g., infrastructure can inherit the priorities of the features).
  • The N in INVEST is negotiable. The intent is that the user story shouldn't overly constrain the user story. Several of your user stories contain specific layout (e.g., sidebar). That should really be part of the annotations (e.g., lo-fi storyboards). You want to be able to approach the user story with an open mind and the flexibility to implement that feature in whatever is best.
  • As I noted in a previous sprint, the skull-and-crossbones is a pretty apt emoji. Entries that large need to broken down into smaller pieces to be estimable (E in INVEST) and implementable in a practical way. The 4s and 8s will likely lead to merge conflicts and other challenges.
  • PRs are most useful when they are an opportunity for review and a chance to prevent errors from creeping into your application. Avoid self merges (no review) and avoid merges with broken tests. I recognize you were working through some infrastructure issues with the tests. In that case, I think you are better off turning off the tests than merging failing PRs. Doing the latter normalizes failing PRs, which increases the chance you will miss true errors in the future.
  • I noticed more tests and PropTypes (and know those are a work in progress). As you solidify your features, both components and pages, make sure to co-develop tests and prop types. It is OK to reject merges without tests!
  • The task about inconsistencies in the data model is a good one to heed. Focus on creating, and really using the associations in your models, e.g., posts or comments belonging to a user. Doing so will making fetching the relevant data much simpler (since Objection can handle the tricky details).

Looking forward in this final sprint, keep an eye on your overall priorities. What is the face of your Mona Lisa? What features are the highest priority to get completed so they are fully functional? Upvoting? What you are aiming to avoid is getting the end of the semester with many, but incomplete, features.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions