The tP spans ten weeks, and is to be done in breadth-first iterative fashion.
The first portion of the tP will be spent of laying out the foundation for the iterations, as illustrated below. This portion of the tP is light because you will be doing the individual project (iP) in parallel during this time.
Note: that the diagrams above show the relative size of tasks i.e., smaller tasks are shown as shorter bars
Week 3 Kickoff
- Form teams.
- Set weekly meeting times.
Week 4 Set direction
- Decide on a general direction for the project (i.e., target user profile, and problem addressed).
Week 5 Gather requirements
- Gather requirements in the form of user stories.
- Decide which of them will go into the first version.
Week 6 Define the MVP
- Decide how the MVP version of the product will look like (i.e., v1.3).
The second portion of the tP is divided into multiple iterations, each of which is expected to produce a working version of the product by evolving the product delivered in the previous iteration.
W7 Iter.1 [ Practice iteration → v1.1 ]
- Learning outcome: Able to follow the workflow as a team.
- Product goal: Update some documents to match the new product direction.
- Strategy: Practice the workflow while updating the documents.
Aim to do 'just enough': Note how the Product goal (together with the Strategy) is simply a means to achieve the Learning outcome. Unlike in a real SE project, the product in the tP exists only to help you achieve the learning outcome. Hence, aim to do 'just enough' work on the product to achieve the intended learning outcome of the iteration (e.g., don't make features bigger than necessary) so that the tP doesn't add to your workload more than necessary.
W8 Iter.2 [ First feature increment → v1.2 ]
- Learning outcome: Able to update functional code while working in parallel.
- Product goal: Take the first step towards an MVP by delivering at least some functionality changes.
- Strategy: Define the smallest possible MVP (simplest versions of must-have features only). Each member tries to merge at least one PR that moves the product towards that MVP.
W9 Iter.3 [ MVP → v1.3 ]
- Learning outcome: Able to deliver a fully working product, on time.
- Product goal: Reach the .
- Strategy: Decide on a plan to meet the MVP delivery deadline. Reduce risk by aiming for the smallest subset of must-have features.
W10 Iter.4 [ Alpha version → v1.4 ]
- Learning outcome: Able to tweak the product/project plan to match the available time/resources.
- Product goal: Implement versions of all the features intended for final release.
- Strategy: Add features based on priority, while maintaining a working product. It is OK if the features are slightly rough around the edges, as the next iteration can still tweak them features.
W11 W12 Iter.5 [ Release candidate → v1.5 ]
This iteration has an extra week, on account of holidays.
- Learning outcome: Able to apply internal quality control.
- Product goal: Reach the release candidate (RC) version, ready for a public beta testing (i.e., the product quality should be sufficiently high e.g., no obvious bugs).
- Strategy: Do an internally, and refine features as necessary. Improve tests, documentation, code quality.
This version (i.e., v1.5) will undergo a limited beta testing (done by other teams) and you will receive the bug reports without any penalty.
W13 Iter.6 [ Public release → v1.6 ]
- Learning outcome: Able to put in final touches while minimizing delivery risks i.e., risks of regressions or deadline overruns.
- Product goal: Reach the quality necessary for a public release.
- Strategy: Freeze features. Strictly limit changes to bug fixes only.
- This iteration is very short (just a few days).
Even minor/cosmetic changes to features are not allowed in this iteration due to the feature freeze enforced. - This version will be subjected to an intensive peer testing (the so-called practical exam). You will get credit for finding bugs in others' tP deliverables and penalized for bugs found in your deliverables.