tP Week 8: First feature increment → v1.2tP Week 10: Alpha version → v1.4


tP Week 9: MVP → v1.3

  1. Plan the first product release (v1.3)
  2. Manage the iteration, and deliver v1.3 Thu, Oct 17th 23:59

Intro to tP Week 9

What's happening this week:

This week, we deliver the first working version of the product (i.e., the MVP), thus finishing what we started in the previous iteration.

v1.3 (MVP)

  • 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.

As per the learning outcome of this iteration (given above), our focus is on delivering a product on time. So, in task 1, we start by setting up a plan to reach that goal, and then execute on it in task 2 , while making course corrections as we go (if needed).

Things to note:

Iteration vs milestone vs version:

An iteration can aim to reach zero or more milestones, some of which can be the release of a product version. So, they are three different things.
For convenience, the tP uses a version number to refer to all three. For example, when we say iteration v1.3, we mean the iteration that ends in the milestone v1.3 (that also happens to deliver the product version v1.3).

How to define version numbers?

While there is no universal set of rules on choosing version numbers for a product, there is a convention named SemVer that is well-defined and widely used. Our tP version numbers (v1.3, v1.5, v1.6 etc.) do not follow SemVer strictly though.

This is your first 'proper' iteration that delivers a product. Ensure you remember how you are expected to 'manage' an iteration (graded), given in the panel below:

1 Plan the first product release (v1.3)

Note that the product you deliver at the end of this iteration must be working although the functionality is basic.

  • Revise the iteration target, if necessary e.g., if v1.2 iteration felt like your progress is much slower than you anticipated, you can explore if MVP can be trimmed-down even further, to increase your chances of reaching it in time.
  • Enumerate the plan: decide tasks, order, timeline.
    1. Figure out what tasks needs to be done to reach v1.3 product version.
    2. Decide if there is a certain order in which they need to be done (based on dependencies between them)
    3. Decide the timeline on which you need to finish each.
  • Document the plan: create issues, assign milestone, and members.
    1. Create issues to match the tasks you enumerated above.
      In the issue description, you can mention when a task needs to be done (e.g., due: Monday). Alternatively, you can create a bunch of labels for recording due dates (e.g., due:Monday)
    2. Assign them to the milestone v1.3.
    3. Assign each of those issues to the person responsible for doing it.

2 Manage the iteration, and deliver v1.3 Thu, Oct 17th 23:59

Ways to level up your tP game:

  • Consider updating the UG as you go. As you implement a feature/enhancement, consider updating the user guide (UG) to match the new behavior.
  • Start reviewing each other's PRs seriously, and giving thoughtful review comments (i.e., as opposed to approving after a superficial look), if you haven't done so already.

  • Manage the iteration v1.3, and reach the milestone v1.3 (which delivers product version v1.3)
  • Aim to delivery on time, as that is linked to our tP learning outcome of this iteration. This means you need to monitor progress, and course-correct as you go.
    • Revise the MVP design further, if needed. If you think some of the ongoing work intended for the current iteration may not finish in time, you can reassign them to a future iteration, provided they are not essential for the v1.3 (i.e., you can still get a 'working product' without them).
    • or issues/PR accordingly.
  • Do a release on GitHub, when the product v1.3 is ready. Requirements:
    • Write a fairly detailed Release Note in the text field GitHub provides for the description of the release. In particular, describe what has been changed (compared to AB3). This is just an itemized list of What's New -- no need to be as elaborate as a user guide.
      Include screenshots (or screen recordings) of your product in action, featuring the changes you've done.
      These release notes will be checked by the teaching team to verify (a) that they are written reasonably well, and, (b) that the features mentioned in there show the product has reached the MVP level of functionality.
    • Upload the JAR file as well. Instructions for creating a JAR file can be found in as described in the tP Developer Guide.
  • Wrap up the milestone on GitHub, when you are done with this iteration and the MVP has been released.

FAQ Should we try to automate GUI testing as well?

FAQ All tests pass locally, but the same code fails CI in the PR. How come?

FAQ PR passed CI before merging, but fails CI after merging. How come?

Some other relevant FAQs, repeated from last week:

FAQ Do we have to update tests when we update functional code?

FAQ PR CI fails because Codecov reports a drop in code coverage. What to do?

FAQ Can we PR against a branch other than master, and merge that branch to master in a later iteration?

FAQ Do we need to update user/developer guides to match code changes?

FAQ Are we allowed to deviate from the MVP Feature Specification submitted earlier?

End of tP Week 9

Phew! Hope your first product release went well, and was on time. If it didn't, not to worry; we have more tries to get it right.

For now, give some thoughts to the following questions (the answer will be needed for an activity in the next iteration):

  • Were you able to deliver on time? If not, why?
  • How do initial effort estimations compare to actual effort? Took more or less effort than anticipated?

tP Week 8: First feature increment → v1.2tP Week 10: Alpha version → v1.4