Goal

  • Develop an original application using Scrum methodology
  • Understand the agile principles of Scrum
  • Understand the difficulties of team development

App Specification

  • The application is written in Go language
  • The app is either one of the following types:
    • a command-line interface (CLI) application
    • a graphical user interface (GUI) application (The environment should be set up on your machine)
    • a web service (The environment should be set up on your machine)
    • a library, that has no user interface, but can be used by other applications
  • Any category of application is acceptable, such as:
    • a game
    • a tool
    • a utility
    • a library; etc.
  • The application should be original and not a copy of an existing one, i.e., it should have a unique value proposition (UVP) that distinguishes it from other applications.

Example Applications

  • Todo list manager
  • Hit and Blow game
  • Bowling game
  • A conversion tool from Markdown to HTML
  • Calculator

Schedule and Instructions

Week 5-1

  • Decide the application to be developed
    • Create a User Story Map to visualize the application’s features and workflow
    • Write user stories that deliver real, testable value to end users
  • Set up the development process
    • Initialize a GitHub repository for the project
      • The final release should be published on GitHub
      • Register a contributor to the repository: username okamumu
    • Define roles and responsibilities in the team
    • Prepare the development environment
      • Tools: GitHub, Project Board (e.g. GitHub Projects), CLI/IDE, etc.
    • Decide the development style
      • Pair Programming / Mob Programming
      • TDD (Test-Driven Development), etc.
    • Establish team policies:
      • Git branching strategy
      • Commit message convention
      • Pull request review policy

Week 5-2

  • Sprint timebox: 90 minutes
    • Sprint Planning: 15 minutes
    • Development: 60 minutes (including optional daily scrums)
    • Sprint Review + Retrospective: total 15 minutes
      • The team can allocate time between review and retrospective as needed
  • The frequency of daily scrums is up to each team
  • The time allocation between review and retrospective is flexible, based on the team’s needs
  • The product should be pushed to the GitHub repository with a tag v1 on main branch at the end of the sprint

Week 6-1

  • Sprint timebox: 90 minutes
    • Sprint Planning: 15 minutes
    • Development: 60 minutes (including optional daily scrums)
    • Sprint Review + Retrospective: total 15 minutes
      • The team can allocate time between review and retrospective as needed
  • The frequency of daily scrums is up to each team
  • The time allocation between review and retrospective is flexible, based on the team’s needs
  • The product should be pushed to the GitHub repository with a tag v2 on main branch at the end of the sprint

Week 6-2

  • Sprint timebox: 90 minutes
    • Sprint Planning: 15 minutes
    • Development: 60 minutes (including optional daily scrums)
    • Sprint Review + Retrospective: total 15 minutes
      • The team can allocate time between review and retrospective as needed
  • The frequency of daily scrums is up to each team
  • The time allocation between review and retrospective is flexible, based on the team’s needs
  • The product should be pushed to the GitHub repository with a tag v3 on main branch at the end of the sprint

Week 7-1

  • Sprint timebox: 90 minutes
    • Sprint Planning: 15 minutes
    • Development: 60 minutes (including optional daily scrums)
    • Sprint Review + Retrospective: total 15 minutes
      • The team can allocate time between review and retrospective as needed
  • The frequency of daily scrums is up to each team
  • The time allocation between review and retrospective is flexible, based on the team’s needs
  • The product should be pushed to the GitHub repository with a tag v4 on main branch at the end of the sprint

Week 7-2

  • Sprint timebox: 90 minutes
    • Sprint Planning: 15 minutes
    • Development: 60 minutes (including optional daily scrums)
    • Sprint Review + Retrospective: total 15 minutes
      • The team can allocate time between review and retrospective as needed
  • The frequency of daily scrums is up to each team
  • The time allocation between review and retrospective is flexible, based on the team’s needs
  • The product should be pushed to the GitHub repository with a tag v5 on main branch at the end of the sprint

Post-processing (After Week 7 until August 6)

  • A seminar room will be available for creating presentation videos from 8:45 to 12:00 on July 30.
  • Please note that no instructor support will be provided during this time. Each team should prepare and record their presentation video independently.

Creating the Presentation Video

  • Each team must create a presentation video with all team members using the recording feature of Microsoft Teams.
  • Submit the video URL using the following form:

Evaluation of Other Teams’ Videos

  • After the submission deadline, each person will be assigned one team to evaluate.
  • Use the following form for evaluation:
  • The assigned team will also announced in the MS Teams channel after all teams have submitted their videos.

Presentation Video

  • The video will be created by each team with the recording feature of the MS Teams meeting
  • The video should be within 20 minutes, and include the following structure:
    1. Introduction
      • Team members and their roles
    2. Product
      • Application name and its purpose
      • Key features and your UVP (Unique Value Proposition)
      • Demonstration of the product (mandatory)
    3. Development Process
      • Explanation of your user story mapping and product backlog (mandatory)
      • Summary of each sprint’s progress (mandatory)
      • Tips, rules, or unique practices adopted by your team
    4. Findings and Reflections (mandatory)
      • What your team learned through this project
      • Any difficulties and how you overcame them

Notes

  • Please enjoy the development process first and foremost.
    The main goal is to experience the fun and challenges of team development through the Scrum process and to gain valuable insights from it.
  • The Scrum Master is responsible for asking the instructor if there are any questions about how to proceed with Scrum.
  • The Product Owner is responsible for creating and maintaining the user story map and product backlog.
  • If all the initially planned requirements are completed before the final sprint ends, the team is encouraged to add new features or improvements to the product.
  • The sprint backlog may include both technical tasks (e.g., implementation, testing) and management tasks (e.g., scheduling, team coordination).
  • All development tools such as AI assistants, code generators, and libraries can be used.
  • The work should be conducted in a given timebox, and the team should not work on the project outside of the scheduled time.
  • Remember, this exercise is not only about building a product, but also about building a team.