Second Release Reflection

Here is our work for Deliverable 4. It contains changes to the product backlog, sprint backlogs, project velocity, difficulties we encountered, use of contingency planning, progression from D3 to D4, and client interactions.

Product Backlog

The product backlog changed since deliverable 3 to incorporate feedback that we recieved from our teaching assistant. Additionally, we added user stories relating to creating expiration dates for restaurant owner bingo boards. We decided to add this feature so that restaurant owners can notify customers that they plan to change the bingo board on a certain date.

The product backlog is as follows or as a pdf here:

Release Plan
  • The length of our sprints continue to be one week long.
  • We chose this length because we want to have a larger number of sprints while still lining up with deadlines.
  • Our releases, including time taken for peer reviews, should fall exactly on each deliverable’s due date, including the final due date of the project.
    • Sprint Plans

    Three sprints were completed and are described in detail below.

    Sprint 2: Backlog
  • For each user story in the Sprint Backlog, there are the following details:
    • Priorities are labelled at the top of each card.
    • Groupings of user stories are shown through the labels.
    • Story points are shown in brackets in the user story titles.
    • 1 story point = 2 hours

    The full sprint backlog is as follows or as a pdf here:

    Sprint 2: Intitial

    The following images contain the initial task board, division of tasks, and burndown chart for sprint 2, respectively.

    Sprint 2: Final

    The following images contain the final task board, division of tasks, and burndown chart for sprint 2, respectively.

    Sprint 3: Backlog
  • For each user story in the Sprint Backlog, there are the following details:
    • Priorities are labelled at the top of each card.
    • Groupings of user stories are shown through the labels.
    • Story points are shown in brackets in the user story titles.
    • 1 story point = 2 hours

    The full sprint backlog is as follows or as a pdf here:

    Sprint 3: Intitial

    The following images contain the initial task board, division of tasks, and burndown chart for sprint 3, respectively.

    Sprint 3: Final

    The following images contain the final task board, division of tasks, and burndown chart for sprint 3, respectively.

    Sprint 4: Backlog
  • For each user story in the Sprint Backlog, there are the following details:
    • Priorities are labelled at the top of each card.
    • Groupings of user stories are shown through the labels.
    • Story points are shown in brackets in the user story titles.
    • 1 story point = 2 hours

    The full sprint backlog is as follows or as a pdf here:

    Sprint 4: Intitial

    The following images contain the initial task board, division of tasks, and burndown chart for sprint 4, respectively.

    Sprint 4: Final

    The following images contain the final task board, division of tasks, and burndown chart for sprint 4, respectively.

    Estimated and Actual Project Velocities
    Estimated Project Velocities
    • Sprint 2: 46 story points
    • Sprint 3: 35 story points
    • Sprint 4: 25 story points
    Actual Project Velocities
    • Sprint 2: 46 story points
    • Sprint 3: 35 story points
    • Sprint 4: 25 story points
    Difficulties We Encountered
    A difficulty that we encountered was figuring out a way to securely connect our Java Android application to our Mongo database. We conducted a lot of our own research, and reached out to our teaching assistant and our client for support. After following tutorials, we realized that many features that allowed Android applications to connect to Mongo databases were no longer supported. Following this, we tried to connect the application to the Mongo database using APIs; however, this feature was not easily supported on the Android emulator. After a conversation with our client, we decided to make our project web-based so that we focus on the functionality.
    How Our Contingency Plan Was Useful/ How It Varied

    Thankfully, there was no need to utilize our contingency plan for this deliverable. From the last deliverable, we were able to complete three sprints. The first sprint we split according to web and application interfaces; however, due to setbacks, our application became entirely web based. Thankfully, the conversion of application to web was not difficult and did not set back the overall project. Overall, everyone was able to get their work done on time.

    The second sprint we split according to feature, where we would implement both the frontend, backend and testing. In this sprint, everyone was able to finish their work on time. In the third sprint there was only one front end and the rest of us implemented the backend features. In this sprint, our estimated project velocity was low. More so, we were all able to finish the frontend and backend implementation early in the sprint. Thus, we decided to clean up the appearance of our bingo board, since in our meeting with the client, that was one of the major things they wanted us to fix. Because of this, we allotted a new task for creating a mockup of the new interface and the implementation of it.

    How to Improve the Next Sprint Based on Experience With This Deliverable

    In this deliverable we learned how to properly peer review, so now we can provide better feedback to our teammates on their code moving forward. We also gained feedback on our user stories, so in the future, we can write better user stories. In addition, we have a clearer grasp of how long it may take us to implement features individually, so calculating these may be easier in the future, and if time permits, we can increase our project velocity for the upcoming sprints. Since we have taken time to learn the tools needed, we can also work more quickly on these features.

    Project Progression from Deliverable 3 to 4
    At the end of Deliverable 3, our team released a simple bingo board interface that allowed users to to select goals from a drop down list of predefined goals, save them to their board, and clear their board to reselect goals. We expanded upon the restaurant user functionality for Deliverable 4, and began development for customers who will use the gamified system. In our latest release for Deliverable 4, restaurant users and customers have dedicated interfaces to sign up to make an account and login. Restaurant users have a customizable profile, and can choose to create, view, and remove custom goals on a dedicated interface. They can edit and save changes to their bingo board with pre-defined and customized goals, as well as rewards from a pre-defined list. For customers, when they log in they can view a list of restaurants with visible profiles, and choose to view the full profile or the restaurant’s bingo board.
    How Deliverable 4 Differed from Deliverable 3

    Deliverable 3 and 4 differed for our team in terms of progress and end result. For Deliverable 3, we allotted lots of time to learn and familiarize ourselves with new tools such as MongoDB and Python Flask. While lots of progress was being made in terms of learning and preparation for the project, the end result had very basic functionality. We also found that having a sprint at the same time as a deliverable caused us to spend more working time on the course than were actually being documented, thus the project velocity may be too high for sprints that coincided with deliverables. For the following sprints, we were able to utilize what we learned during the first sprint to make significant progress.

    The second and third sprints remained with high project velocities because there were no deliverable due dates; we were able to use the tools we learned in the first sprint to make progress on the project. The fourth sprint occurred during the same week as Deliverable 4, so our team decided to reduce the velocity to allot time for the report. As mentioned in the previous section, we added various functionalities that built on what we produced in Deliverable 3. As a result, the end result included more implemented features.

    Our deliverable also differed because of feedback we received from the client. After we demonstrated our first deliverable, the PickEasy team gave us feedback on our design; they mentioned they wanted a different way to select goals instead of a dropdown list, and a more aesthetically pleasing interface. We used this feedback to design the bingo board interface that eliminated the drop down list in favour of clicking and dragging goals and rewards onto the game board.

    Client Interactions
    Client Interactions and Questions Asked

    PickEasy had some inconsistencies with the timing of their Thursday meetings for a few weeks, so many of our interactions with our client occurred over email. The following states the date of the email/meeting and the questions we asked.

      June 19, 2020
    • Do you want there to be a feature where customer users can see all their past rewards? Or is this an inventive feature?
    • Should there be accounts for restaurant owners?
      • July 4, 2020
    • We are creating an Android app using Android Studio and trying to use an API to connect to MongoDB; we are having difficulties doing so and were wondering if you had any experience with this.
    • The app is very large in size due to all the dependencies, and we were wondering if you have any suggestions about deployment methods.
    • If we are unable to deploy an app because of the above limitations, would a web-based loyalty program be an acceptable solution?
      • July 8, 2020
    • Should the bingo board be pre-filled with a randomized list of goals for a restaurant owner?
    • What is your opinion of the bingo editor interface in terms of design?
    • We were thinking about having the goal tracking system be similar to the coupon redemption system where a customer will present a QR code and the restaurant owner can scan it to accept a goal, since we do not have experience with Shopify or Square. Would this be fine?
      • July 10, 2020
    • Should the customer and restaurant user interfaces be completely separate (with two individual domains) or should there be one main page that has two options for the two different types of users?
    Demo of First Release: Meeting Minutes

    On July 8, 2020 at 3:00 p.m., we demonstrated our first release to our client. The following states the demonstration agenda, questions asked, and feedback from the client.

      Demonstration Agenda
    • Show login/create account pages
    • Show bingo editor
      • Explain setup of bingo board; premade goals, goal boxes, achievement paths, and rewards
    • Show mockups for customer interface
      Questions
    • What do you think of our bingo idea?
      • Any suggestions?
        • 3x3, 4x4 etc.
      • Should it be pre-filled with a randomized list of goals for a restaurant owner?
      • What’s your opinion of the bingo editor interface in terms of design?
    • In terms of POS integration, we don’t have any experience with Shopify or Square, so our group will most likely not be using these to track goals.
      • Instead, we were thinking about having the goal tracking system be similar to the coupon redemption system where a customer will present a QR code and the restaurant owner can scan it to accept a goal. Would this be fine?
      Feedback from Client
      • Wants customizable goals by the owner, not pre-populated
      • We can use Qr codes for our coupon system, but prefers if we could integrate the project with Shopify
      • 5x5 game board with the drop down menu is fine
      • Game board set up is not aesthetically pleasing
      • Wants us to focus more on the execution and customer side
        • How the users would see and interact with the board