You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Key: Exceeds Expectations (EE), Meets Expectations (ME), Below Expectations (BE), Falls short of expectations (FS)
Checklist: ME
User stories: ME/BE
Supporting materials: ME
Some process notes:
Great use of review on your Pull Requests (PRs)! Keep it up! In particular, heed to the feedback on the pending PR for Knex. That PR seems incomplete (and maybe more like a spike - see below). I encourage you to break into parts, some of which are complete or develop it to the point of being a complete feature, even if a small one, before merging into main.
Some notes about user stories:
We advocate the Connextra format ("As a .., I want to ..., so that ...") across all granularities (from "epics" on down) so it is clear who this feature is for and why they want it (the value/motivation). Who is the stakeholder(s) for your epics and why do they want/need that feature. The latter is critical for prioritizing your work (is this feature really needed?). Try to structure your Epics in the Connextra format and make sure those (and your user stories have clear motivations).
We don't have a notion of User Stories as a separate category. The product backlog should be populated with user stories (and other work) derived from your epics. The distinction is that while Epics can have very large scope, the user stories in your product backlog should be sufficiently concrete and fine grain so that you could choose subset of those items to make up your sprint backlog for sprint 1 (i.e., what you think you can complete in the next two weeks).
Some notes about supporting materials:
The CRC cards are a great start. I would encourage you to compare those with your developing schema to identify possible tricky problems you need to resolve, or areas for further design. For example, to what extent you can unify your different types of users into a single model. A keep concept to investigate here would be single table inheritance.
Aim for your lo-fi storyboards to be that, storyboards. How is a feature actually used? What components are implied?
Thinking about sprint 1:
I want to encourage you to think about what spikes, i.e., time limited exploration of unknown technologies/tools, you want or need to perform. For example, managing user models that might be similar without duplicating code (single table inheritance).
The text was updated successfully, but these errors were encountered:
Key: Exceeds Expectations (EE), Meets Expectations (ME), Below Expectations (BE), Falls short of expectations (FS)
Checklist: ME
User stories: ME/BE
Supporting materials: ME
Some process notes:
main
.Some notes about user stories:
Some notes about supporting materials:
Thinking about sprint 1:
The text was updated successfully, but these errors were encountered: