Sprint 1 Feedback

[mlinderm]

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

User stories: ME/BE (minimal users stories, often with no motivation and detail)
Agility: ME/BE (minimal use of the backlog)
Integration: ME/EE (PRs with communication, no broken builds)
Implementation: ME/EE (awkward architecture, multiple tests, back and front-end implementation)
Functionality: ME (no persistance yet)

As a logistical node, make sure to tag your sprints.

• Aim for specific user stories with clear motivations. While not all tasks will fit in the Connextra format, all should be clear and clearly motivated. For example, in "As a Middlebury student, I want be able to push a button to let people know if the cafeteria is busy." While the feature is clear and specific, the motivation, and its impact on the implementation, is not. Why would a student in line want to do that? How would that motivation influence your design? Specifically how would you encourage/incentivize that action? Via altruism, a reward built into the application? Clear motivations will help you prioritize the work and guide your design.
• The specific sizes only have meaning within your team, but looking at your scoring 4 might be a sign a tasks needs to be broken down further. For example, "As a student, I want to know the historical busyness / menu." does not currently seem estimable (i.e., can estimate the work involved). Where will you obtain/generate that data? How will it be analyzed and displayed?
• The sprint backlog represents a to-do list of sorts. The goal is to have enough "work" in there to keep the team busy (at a consistent and sustainable level for the whole sprint). Aim for more user stories/tasks than teammates, and a range of sizes so there is a task available for everyone when they are working on this class.
• Great use of size tags! The goal is to use those tags to estimate velocity and plan future sprints accordingly. Aim for a consistent and sustainable velocity. If your spring backlog has fewer points than your team's capability that might indicate you are underestimating, or you have more capacity in the sprint than you are utilizing.
• Aim for consistent progress throughout the sprint, e.g., avoiding commit/integration pileups at the end of the sprint. That is a recipe for frustrating merge conflicts.
• Great use of PRs. I particularly notice the interaction between team members, that reviewers were actually trying out the code, and the merged builds were passing.
• Great to see tests! Don't ignore PropTypes, though. They are another important part of our documentation and error catching approach.
• I made an issue with specific line-level comments as I looked through the code. I would also suggest organizing your API for the future, e.g., the existing routes are relevant to a dining halls, so I would organize them under that resource, .e.g, /api/places/[id]/ to keep that id distinct from other ids in the application.
• Going forward, aim to evolve the front-end and back-end at the same time. 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.

It looks like the persistence layer will be one of the big tasks for sprint 2. I encourage you to get that in earlier rather than later so it doesn't become a blocker. As you are doing so, use that as a moment to think through your data model (e.g., via the CRC cards) as will impact your DB design, API and front-end design (which pages you create). In particular how are you to organize the data you collect, e.g., on busyness, tastiness, etc.