- Plan the first product release (
v1.3) - Manage the iteration and deliver
v1.3Thu, Oct 15th 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 work, although its functionality is basic.
- Revise the iteration target, if necessary -- e.g., if progress in the
v1.2iteration was much slower than you anticipated, you can explore if the MVP can be trimmed down even further, to increase your chances of reaching it in time. - Enumerate the plan: decide tasks, order, timeline.
- Figure out what tasks need to be done to reach the
v1.3product version. - Decide if there is a certain order in which they need to be done (based on dependencies between them).
- Decide the timeline for finishing each task.
- Figure out what tasks need to be done to reach the
- Document the plan: create issues, assign milestone, and members.
- 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). - Assign them to the milestone
v1.3. - Assign each of those issues to the person responsible for doing it.
- Create issues to match the tasks you enumerated above.
2 Manage the iteration and deliver v1.3 Thu, Oct 15th 23:59
Ways to level up your tP game:
- Consider updating the user guide (UG) as you go. As you implement a feature/enhancement, update the 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.
Finishing the iteration on time is no longer 'optional'!
From the v1.3 iteration, the v1._ on time item in the tP dashboard will turn red and remain red if the iteration wasn't wrapped up properly by the deadline (i.e., Thu 23:59).
Reason: Learning to meet project deadlines is an intended learning outcome. As this is the third tP iteration, you should be able to finish iterations on time by now.
- Manage the iteration
v1.3, and reach the milestonev1.3(which delivers product versionv1.3). - Aim to deliver 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 items 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/PRs accordingly.
- Revise the MVP design further, if needed. If you think some of the ongoing work items 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
- Do a release on GitHub, when the product
v1.3is ready. Requirements:- Write fairly detailed Release Notes 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 made.
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 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 the tP Developer Guide.
- Write fairly detailed Release Notes 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.
- Wrap up the milestone on GitHub when you are done with this iteration and the MVP has been released.
Some other relevant FAQs, repeated from last week:
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 thought to the following questions (the answers will be needed for an activity in the next iteration):
- Were you able to deliver on time? If not, why?
- How did your initial effort estimates compare to the actual effort? Did it take more or less effort than anticipated?