Quinn Cheong

Quinn Cheong

Place where I document my failures and successes for personal analysis.

Introduction

This module is quite tedious, but heavily mimics what real-world development is like, and is very useful. It is not hard to score, but requires discipline.

Module Overview

IS212 teaches you how to manange a software project. You form groups that closely mimic how real-world software teams operate. You have:

  1. Software Engineers
  2. Product / Project Managers
  3. Scrum Master (double hat with (1))

Your role is to deliver a product with x number of simple features. You must use the agile methodology, and you must use Scrum.

This module took up about 5-10h per week, about 10-20h during project submission season. The module is tough not because it is very application-feature heavy, but involves discipline to sit through the entire process.

Component Breakdown

  1. User Story Assignments
  2. Project
  3. Quizzes + CP
  4. Finals

Grade Breakdown

If you are aiming for A/A+, you will need to score well on Project, finals and User Stories. I scored well on all components.

If you are aiming for B+/A-, focus on project and finals.

General Strategy

This module requires a mix of deliberate practice and memorisation techniques. The key to scoring for projects is to be deligent and handle your sprints well, watching your burndown charts etc.

My advice is not to fake any results. We didn’t need to fake any results and we scored well. Not faking anything will allow you to understand how real-life software development works.

User Story Strategy

It is not easy to write good user stories. You must understand what makes a good user story. You will be given a large chunk of text to derive user stories from. Ensure that you read every line. There are many things that are found in separate paragraphs, yet should be included in your user story.

Here are some tips to follow:

  1. Be clear in your user story
  2. Follow the exact user story format
    1. As a <INSERT ENTITY/USER>
    2. I want to <REASON/ACTION>
    3. so that I can <VALUE IT BRINGS>
  3. Have accurate and comprehensive Acceptance Criteria.

For (1), you should not be rambling. Make your title concise, and ensure that the user story does not have unnecessary jargon.

For (2) and (3), I will show the example which I used.

My submission of a large user story

Most notably, take note of the following:

  1. My AC is split into Rules and Scenarios. You will learn Scenario-based AC for Assignment 2. For assignment 1, rules based is enough.
  2. I included response times and desktop-mobile device ACs. Note that these kind of extra requirements are usually found separate from the paragraph of text that you’ve found the feature. They are usually found towards the end, or during the introduction. You must include all these features.
  3. Notice how it is very easy to eyeball the Rules and Scenario ACs. You can go through them like a checklist. Yours should also be easily readable.
  4. My “value delivered to user”, accurately links back to the “action of the user”. Examples:
    1. [BAD] I want to eat ice cream because I hate oranges
    2. [BAD] I want to eat ice cream because I am not hungry
    3. [GOOD] I want to eat ice cream because I am craving it now
    4. [GOOD] i want to eat ice cream because I want to eat desserts after dinner.

This might seem really simple, but when you’re writing your user story for the first time, it won’t come naturally. Best is to ask your group mates to proof read your first draft. They will immediately know if the value and action links.

Project Strategy

This is the huge chunk of your work. You can view our project here.

There are many moving parts and I will try my best to breakdown the different sections.

Scrum Process

You should do 4 sprints. You only need to submit 3, so use the first sprint as a trial sprint. Our first sprint was bad, but next 3 was good.

Your sprints should look something like this:

  1. 3 daily standups / week, 15mins max. Yes, we kept it < 15mins. No discussion of problems. Just understand blockers, and hold separate meetings to unblock.
  2. Product Backlog Grooming (30-60mins) - to groom your backlog, and polish it up. Usually done directly before Sprint Planning.
  3. Sprint Planning (30-60mins) - Plan for your next sprint, usually with planning poker and sprint goals.
  4. Sprint Review (60mins) - Go through Definition of Done for completed items, ensure everyone is updated on new changes.
  5. Sprint Retrospective (15mins) - What went well, what can be improved, questions, action items.

This is how a good retro looks like. Photo of Sprint Retro

Charts

This is a bad burndown chart Bad Burndown Chart

This is a good burndown chart Good Burndown Chart

You should submit other charts as well:

  1. Burnup Charts
  2. Velocity Chart
  3. Final Sprint Backlog - Does not need to be finished. Our backlog still had many other features.

We used Jira, and I highly recommend using Jira. It’s very easy to handle all your sprints as a group and automatically generates charts. I can’t say exactly how to write the user stories, but you should refer to the user story above. All our user stories were to the same level of detail.

Test Cases

We had about 200-300 test cases.

Testcases

CI/CD and PR Template

We used a PR template for our pull requests. We did feature-based branching strategy. We had Github Actions for our CI/CD pipeline, which handle our linting (using Python Black formatter) and ran our python unit tests with pytest - yes we wrote unit tests, no need integration tests.

# Description
<!-- Please add link to Jira Ticket here -->
Fixes [Jira ticket #]()
<!-- Add Screenshots if there are changes or additions in frontend components -->

List all acceptance criterias of user story and indicate which has been solved previously and which is solved currently
- [x] XXX (solved)
- [x] XXX (solving)
- [ ]

## Type of change

Please delete options that are not relevant.

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Refactor
- [ ] Migration

# How Has This Been Tested?
- [ ] I have added the corresponding testcases into the [testcase document]()

Please indicate the testcase ID you have added or are using

- [ ] G7T5-1-1
- [ ] G7T5-1-2

# Checklist:

- [ ] I have added the appropriate labels to my PR
- [ ] My code follows the style guidelines of this project
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

Other Documentation

We had an overall submission word docx which outlined our overall guidelines. Overall guidelines

We included images of our git flow strategy for clarity. Git Flow

We also had a BPAS diagrams of the different user flows for clarity. Business Process Diagram

Lastly we included Entity Relation Diagrams so we could visualize our DB. Entity Relation Diagram

We produced a C4 model as well but no photo here.

Final Strategy

Memory Techniques are the way to go for finals (as of 2023). Check back with your professor for sample final paper questions. For me, finals was memory questions with some applications. For example:

  1. What testing quadrant is unit test in?
  2. What is red-green-refactor?
  3. How is the customer involved in waterfall vs scrum?
  4. When to use feature vs trunk based development?

Finals should also test some OOP. This will be very basic OOP, and you should try to score in this area. Remember to study for it.

Conclusion

This module really focus on the process. It’s not about how nice your UI looks, how bug free your application is, and even not about how many extra features your application has. You’ll need very strong documentation, good charts, and some discipline to tide this module over.

Hope you score well :)

You May Also Enjoy