The tP spans ten weeks, and is to be done in breadth-first iterative fashion.
The first half of the tP will be spent of laying out the foundation for the iterations, as illustrated below (note that the diagrams above show the relative size of tasks i.e., smaller tasks are shown as shorter bar).
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 Conceptualize the product
- Decide how the product will look like at v1.2.
- Record that product concept in the form of a user guide.
Week 7 Do a practice iteration → v1.1
v1.1
- Product goal: Update some documents to match the new product direction.
- Process goal: Get ready for proper iterations.
- Strategy: Practice the workflow while updating the documents.
- Ensure development environment is set up.
- Do a practice iteration (v1.1) to get used to the workflow. In this iteration, only some documents will be updated.
- Plan the next iteration i.e., decide who will do which parts by when.
The first half of the tP is light because you will be doing the iP in parallel during that time.
The second half of the tP is divided into three iterations, each of which is expected to produce a working version of the product by evolving the product delivered in the previous iteration.
W8 W9 Iteration 1 → v1.2
v1.2
- Product goal: Reach a minimum viable product (MVP).
- Process goal: Estimate the quality and quantity of manpower i.e., see how much the team can do within an iteration.
- Strategy: Define the smallest possible MVP. Reach it as soon as possible. Use the remaining time to see how much more work the team can do, while staying within own workload limitations.
- This is the first proper iteration.
- Aim to deliver an version of the product.
W10 W11 Iteration 2 → v1.3
v1.3
- Product goal: Reach the release candidate (RC) version.
- Process goal: Tweak the product/project plan to match the available time/resources.
- Strategy: Add features based on priority, while maintaining a working product.
- This version will be tested by peers and you will receive the bug reports without any penalty.
- Aim to deliver all so that you can get them tested for free.
W12 Iteration 3 → v1.4
v1.4
- Product goal: Stabilize the product for release.
- Process goal: Minimize delivery risks i.e., risks of bugs in the product, or overshooting the deadline.
- Strategy: Limit changes to bug fixes only. Improve tests, documentation, code quality
- This iteration is shorter (slightly more than one week).
- Changes to features are not allowed in this iteration. Use it for bug fixing, code quality improvements, improving the tests, and polishing up documentation only.
The final submission will be at the start of week 13. Deliverables include an executable jar file, a product website (containing both user and developer documentation), a demo video, among other things.
W13 Evaluation
- The final submission is subjected to a intensive peer testing (in a so called practical exam).
- You will get credit for finding bugs in others' deliverables and penalized for bugs found in your deliverables.