Sprint 1 Feedback

[mlinderm]

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

User stories: ME
Agility: ME/EE
Integration: EE (PRs, review, interaction)
Implementation: EE
Functionality: EE

• There are some great user stories in there, and some that could benefit from more clarity, particularly around motivation. I contrast "As a student, I want to be able to edit features of my profile (name, pronouns, bio, etc.), so that my profile best represents myself.", which has clear features and clear motivation with "Make a new db table, model, etc. for analytics -Liam". While not all tasks will fit in the Connextra format, all should be clear and clearly motivated. What is the motivation for analytics? How will it be used? The answers to those questions will impact the design and implementation. Clear motivations will help you prioritize the work and guide your design.
• Great use of item scores. The goal is to inform estimates of your velocity so you can work at a consistent and sustainable pace. The size can also be an sign that a task needs to be decomposed to actually be practically implementable. For example, how could you break down the extra large As an administrator, I want to be able to view an aesthetic, intuitive, and meaningful analytics page #43 "As an administrator, I want to be able to view an aesthetic, intuitive, and meaningful analytics page" into smaller, more tractable, tasks. Recall that our tasks should be estimable, and if it is X-large, it is probably not meaningfully estimable.
• Try to minimize long-lived branches as they make merges that much trickier. I recognize it is tough at first as the project is getting established and it is unclear how long certain tasks my take. But as your workflow stabilizes aim for smaller tasks that can be completed without long-lived branches.
• Great use of PRs. I particularly notice the reviews and that PRs don't have broken builds.
• Great to see tests! Keep it up. Looking at the sprint 1 tag, you are already at the point where the test files are getting a little overstuffed. Consider breaking those out by resource/topic. Note that component tests can live "adjacent" to the component in the component directory, we need the __tests__ folder for pages because test files in the pages directory would be interpreted as other pages.
• Don't ignore PropTypes. They are an important part of our documentation and error catching approach.
• As front-end organization evolves, make sure to remove previous placeholder files. It looks there are quite a few pages at the top-level, e.g., posts.js that are on their way to becoming part of a richer interface. Leaving the placeholders around increases the chance the the team accidentally creates two implementations.
• I also created some issues about specific code as I was looking through.
• At present it looks like the front-end and back-end have been evolving somewhat separately. This is not unusual at these early stages. To avoid mismatches were they meet, I encourage you to have each developer (or pair) take on a feature in its entirety, i.e., co-develop the front-end and back-end implementation.

Looking forward, keep up the great work! You are making great progress! Focus on breaking down tasks into smaller units of work that enable the distributed asynchronous work required by our class setting (where folks are working on the project in small discrete chunks).