Introduction
This project will involve working with a Twitch (https://www.twitch.tv/) streamer to build a plug-in for their stream on the platform. The client participates in a yearly charity stream for the non-profit organization Extra-Life (https://www.extra-life.org/) where she collects donations from viewers for BC Children’s Hospital. The next Extra-Life event is coming up in mid-November, so the client would like the plug-in well in advance of this date in order to have runway to integrate the plug-in into her stream.
Project Description
The goal of this project is broken into two distinct parts, the first being the core objective of the project and the second being a stretch goal.
Primary Project Deliverable
As mentioned, the client has an upcoming streaming event mid-November. This event centers around collecting donations from viewers. Viewers can donate to two locations: the Extra-Life site and the facilities built into twitch (subscriptions and ‘bits’). A Twitch plug-in needs to be built that can pull donation numbers from both Twitch and the Extra-Life databases. In addition to tracking donations, the plug-in will need to track and manipulate remaining stream uptime, perform on-screen announcements, and allow the client to configure several properties such as time added per donation. A more detailed requirements document will follow this one.
Stretch Deliverable
The stretch deliverable is to create a small game that integrates with Twitch chat in real-time. The game will allow viewers to enter commands in chat in order to manipulate gameplay and have a chance to win various stream related prizes.
Development Model
In addition to providing its core functionality, the plug-in needs to ‘feel good’ to the client while using it. This is an extremely subjective measure, so it will be important to get something into the client’s hands quickly in order to get feedback and course correct if necessary.
Given this, I will be using an iterative development/agile approach to this project, with an emphasis on early tracer code. Tracer code in this context is an activity similar to prototyping, but with the goal of building a ‘placeholder’ plug-in as quickly as possible. When writing tracer code, the code demonstrates minimal (and placeholder in some cases) functionality to the user but is built using the paradigms and quality expected in final code. As a result, the tracer code isn’t discarded at the end of the prototyping phase. Given the relatively short timeline for this project, I’ve chosen this method to maximize the value of my time spent.
A high-level requirement gathering activity will be done upfront in order to identify the client’s primary needs. This will inform research into applicable APIs as well as what will need to be included in the tracer prototype. From this requirements list, a prioritized backlog of epics will be created and estimate point sizes will be assigned to each epic. These estimates are likely better described as ‘guesstimates’ at this phase as they are not intended to be highly accurate or precise but are instead to indicate a guess of relative levels of effort between each item for the client to review. At the start of each sprint (see more below), items will be pulled from the backlog and broken down into more granular pieces.
I will be using sprints to organize work and set immediate goals. Sprints will be in two-week intervals and will begin with the aforementioned process of breaking down the highest priority items in the backlog. These items will then be pulled into the sprint based on what I think I can accomplish in this two-week period. At the end of each sprint, I will perform a review of progress with the client as well as a brief backlog grooming activity to ensure current backlog priorities are still accurate.
I will also be adding two hardening weeks into the project. The purpose of these hardening weeks is to focus on any known outstanding bugs or overhang from previous sprints (if any). Further details on the timing of these weeks are noted in the project timeline section below.
Why this model?
I have chosen this model due to the need to put something into the client’s hands quickly to elicit feedback. Throughout the project I want to make sure that I am prioritizing the most important items to the client. The reality is that they may realize they need changes after seeing an initial prototype, or unanticipated discoveries could be made during development that will require a rapid pivot. By taking an agile approach, we aren’t throwing away our documentation and plans every time this happens.
In addition, the tracer code prototype model will support the goal of getting a minimum product to the client early in order to better align my work to the client’s needs and expectations. The tracer code prototype will be considered the first major iteration.
Weaknesses
Approaching iterative and agile development in this way makes measuring progress difficult. Even when items are broken down to more granular levels, estimates won’t be perfect. In addition, I will be using relative point sizes instead of by-day or by-hour estimates, so measuring how much remaining work is left in the project is unintuitive.
To combat this weakness, each sprint will end with a short velocity analysis to determine the average number of points completed per sprint so far. I will use this number to determine how many points to pull into each sprint and to provide a rough measurement of remaining project time. Obviously because I have no historicals for this project, the number of points I pull into the first sprint will be a guess.
It is worth noting that I have limited experience with the technologies required for this project, namely web languages such as JavaScript (I am typically a desktop application developer). I also have no experience with the Twitch or Extra-Life APIs. A more waterfall-oriented approach would prioritize reducing this risk through upfront research and design, whereas I’ll be carrying this risk through the project.
Planned Project Timeline
Before discussing the project timeline, it is important to note that this plan only reflects the creation of the donation tracker and Twitch integration. The stretch goal game will be built if the plug-in project ends up being far more condensed than anticipated. However, the requirements gathering, analysis, and design will still cover the game so that this work is already done in the event it gets built.
My goal is to complete the project within twelve weeks, dividing it into two milestones of four and eight weeks respectively. The first milestone will be the completion of planning documentation (this document and the requirements, analysis, and design documents), as well as completion of the plug-in tracer prototype. This milestone’s four weeks will be divided into two sprints.
The second milestone will encompass ‘production’ work which will be taking the placeholder features of the prototype to a final state. This time period will also include adding features that may have been missed in the prototype or added after the fact. The eight weeks of this milestone will be divided into three sprints and two hardening weeks. The first hardening week will take place after two sprints, with the second hardening week being the last week of the project.