Skip to content

Latest commit

 

History

History
332 lines (210 loc) · 17.8 KB

PREVIOUSREADME.md

File metadata and controls

332 lines (210 loc) · 17.8 KB

Second Sprint

Sprint Planning (1 point)

The forecast for the second sprint is 20 story points.

  • Receipt metadata (3 points)

  • Sort by date/amount/store name (1 point)

  • Delete receipts (3 points)

  • UI prototype (13 points)

Forecast Rationale (1 point)

The forecast was an increase from the previous sprint because of a few reasons. First, we were able to finish the initial setup of the project quicker than our expectation, which allowed us to start thinking about the code and how we are going to accomplish the user stories. Second, team members were able to complete high story points in a short amount of time during the first sprint. Thus, at the second Sprint Planning session, the team felt confident that they would be able to achieve higher story points in this second sprint.

Sprint Planning Event (4 points)

On Sunday, Nov 15, the Development Team met and participated in the Sprint Planning event.

  1. We pulled stories from the Product Backlog into the Sprint Backlog. This is visible in Miro board where we’ve differentiated between the 2 backlogs using a deck card as a separator.
  2. The stories that were pulled to the Sprint backlog were representative of the Sprint Review Next Steps slide as seen in the screenshot below. These stories were aligned with our stakeholders requests.
  3. The aggregate size of the stories is 20 points, which is equivalent to our forecast this sprint.
  4. Only Development Team members participated in this activity. As evident in the log of Miro board below, during the time of this event, several members of the Development Team were active on Miro board.

next%20steps.png

miro%20log.png

Backlog Size (1 point)

Each backlog item is less than half of the sprint's forecast. The smallest item is 1 story point, and the biggest item is 7 story points. https://miro.com/app/board/o9J_kg1b1Ck=/

User Story Decomposition (2 points)

We decided to use a purple card to represent a Story and a blue card to represent a Dev Task. Additionally, Dev Task is prefixed with the word "Dev Task". Using this color rule, we can easily identify tasks from stories. A Story may have more than 1 Dev Task. Here are some examples of a Story and some Dev Task underneath it.

story_devtasks1.png

story_devtasks2.png

Sprint Backlog Format and Accessibility (3 points)

  1. Our Sprint Backlog is represented in a Kanban board in Miro.
  2. The URL to Miro is: https://miro.com/app/board/o9J_kg1b1Ck=/
  3. Richard helped set the board and by virtue of access should be able to view the URL above.

Sprint Burndown Chart (6 points)

  1. We have a Sprint Burndown Chart located above the image of a Strawberry on our Miro board: https://miro.com/app/board/o9J_kg1b1Ck=/
  2. The x-axis represents dates of the sprint by day.
  3. The y-axis represents story points remaining to be done.
  4. We tried our best to keep a linear curve descending from left to right, however, in the middle of the Sprint, we realized that we did not incorporate CI/CD User Stories to the Sprint as required by the grading rubric. This is why you will see a spike in the chart about at around mid-sprint.
  5. The URL to the burndown chart is: https://miro.com/app/board/o9J_kg1b1Ck=/
  6. Richard helped set the board and by virtue of access should be able to view the URL above.

Daily Scrum (1 point)

On Nov 24, the Development Team conducted a Daily Scrum as shown below:

daily_scrum_11_24.png

Daily Scrum - What did you do? (5 points)

  • Rick: Deployed application to a Linode server. Sent messages to Richard regarding handling project requirements vs stakeholder requests, and resubmitting homework.

  • Diah: Kept up with all thread on Slack, Re-did Sprint burndown chart, Calculated the Rubric for Project Part 2 and started gathering evidence to resubmit.

  • Remi: Worked on meta-data upload. Files now are uploaded to the database with meta-data. (Handles the create function from CRUD)

  • Will: Worked on meteor and Vue learning and playing around with the current code.

  • Davey: Implemented views for logged-in/logged-out/unregistered users.

Daily Scrum - What will you do? (5 points)

  • Rick: I will start working on integrating CI/CD for automated testing and builds

  • Remi: I will help in writing and running unit tests for TDD.

  • Diah: Create slides for Sprint Review. Continue to gather evidence to resubmit. Continue to fill in Project Part 3 rubric.

  • Will: I will make small visual and logical updates to the UI to better fit the mockup.

  • Davey: I mentioned I’ll work on repairing my computer, which blew up.

Daily Scrum - Any impediments? (3 points)

There was one impediment that was brought up at the 11/24 Standup:

  • Davey: Yes, I did encounter an impediment. My impediment was a critical failure of a backup restoration process after my laptop returned from the repair shop. It caused data loss, irreversibly, to my great dismay. My plan was simply to reinstall lost programs and let go of the data that was lost, which I did.

Update Sprint Task Board and Burndown Chart (2 points)

Different members updated the Kanban board on different days as they progress with the assigned stories as seen in the log below:

daily_log.png

Als, as seen in the screenshots below, the Sprint Burndown Chart was updated from Nov 29 to Nov 30.

burndown_11_29.png

burndown_11_30.png

Pair- or Mob-Programming (5 points)

On Monday, Nov 16, Diah, William, and Davey did a mob programming of the UI prototype design. Diah was sharing her screen and was acting as the Driver while William and Davey were acting as the Navigators. After the meeting was over, we shared the results of the prototype in the Slack channel for the rest of the team members to see.

mob_11_16.png

On Sunday, Nov 29, starting around 9:40pm, Remi, Rick, William, and Diah participated in a mob-programming activity. Remi was acting as the Driver while the rest of the participants acted as Navigators. The team was testing the CD, where the team changed a color of an h2 element to Red and it worked.

mob_11_29.png

Test-Driven Development (10 points)

We added new tests to ensure that images of different extensions and sizes can be uploaded using Meteor-Files tests.png

Sprint Review (1 point)

On Friday, Nov 27, we conducted Sprint Review around 9:30pm EST. The meeting was recorded and the recording has been shared to Richard at richard@kasperowski and Anu at anupreet.saini@gmail.com. The direct link is here:https://drive.google.com/file/d/1iAYzKZvlIJXppTKp6OgISdEkDTe1FeuP/view?usp=sharing

Product Increment (4 points)

  1. The product is a working software.
  2. It is available on a Linode server available to anyone with a URL link.
  3. If you visit that URL, you will be greeted with the following page:

receipt_catcher_app.png

  1. The URL is: http://96.126.97.44/

Stakeholder Presence (2 points)

  1. As evident in the Sprint Review recording, our stakeholder, Tressa Jamil was present at the Sprint Review.
  2. When presented with the Next Steps slide, she was in agreement and in favor of our proposed plan. During the demo, she was appreciative and did not ask for features outside of our Next Steps.

Continuous Integration (5 points)

  1. We have a Continuous Integration system running.
  2. We only work on the main/trunk/master together-there are no long-lived code branches.
  3. The CI system automatically builds our code every time we push to main/trunk/master.
  4. The CI system automatically executes all our tests every time it builds the code.
  5. Evidence that CI system exists and behaves properly:

https://app.circleci.com/pipelines/github/shariq1989/receipt-catcher

Steps that are run as a part of our CI. They run automatically when code is pushed to main

CI.png

Tests are run automatically in the server_tests job

CI2.png

CI and CD running automatically for every push to main

cicd.png

Continuous Delivery (5 points)

  1. We have a Continuous Delivery system running.
  2. When the build is "green", the CD system deploys our software to production environment ("Production");
  3. when the build is "red", the CD doesn't alter Production.
  4. The CD system executes additional tests of our software in Production to ensure Production is up and running successfully after deployment.
  5. Evidence that CD system exists and behaves properly:

Evidence of CD deployments working

We changed the color of "Select an image" from black to red. Here it is in the original black color.

red1.png

You can see here that we updated the CSS and pushed the change under commit message "testing CD"

red3.png

Here is the corresponding test and deployment for that commit message "testing CD"

red4.png

In the same production instance, the color is now red.

red2.png

Build deployment steps including verification.

CD.png

CI and CD stages run for green builds

cicd.png

Deploy job was not initiated because I added a failing test

FAILCD.png

Sprint Retrospective (4 points)

  1. On Sunday, Nov 29, all members of the Development Team met to conduct a Sprint Review.
  2. The participants were asked to pick a color for a sticky note. As seen on the Miro screenshot, the color legend is on the right side of the Retrospective Wall.
  3. The team identified a room for improvement, which is around more mob- and pair-programming activity is needed especially around TDD for the next sprint.
  4. To accomplish that plan, the team agreed to participate in mob- or pair-programming session right after every Daily Scrum throughout the course of the next sprint.

retro_sprint2.png

First Sprint

Story Point Forecast

14 points

Forecast Rationale

Since this is our very first sprint, we don’t have any historical reference to go by. The team decided that the first four stories, totaling 14 story points is a good start.

Sprint Planning Participation

On Wednesday, Nov 4, at 9PM Eastern Standard Time, all team members of Team Strawberry participated in Sprint Planning as shown in the Zoom participant list below.

sprint_planning

Kanban Board

The color gray denotes the product backlog, whereas purple or blue (dev tasks) refer to sprint backlog items.

https://miro.com/app/board/o9J_kg1b1Ck=/

Sprint Burndown Chart

https://miro.com/app/board/o9J_kg1b1Ck=/

Daily Scrum

On Friday, Nov 6, at 9PM Eastern Standard Time, all team members of Team Strawberry participated in the first daily scrum as shown in the Zoom participant list below.

daily_scrum1.png

What did you do?

11/6

Diah - I shared this Google Document with the rest of the team members. I created a recurrence meeting on Zoom to host Daily Scrum meetings moving forward. I started a HTML and CSS file for the simple UI story to upload pictures..

Remi - set up MongoDB instance and provided team members with access to it

Rick - provided Remi with IP address and asked Richard questions about tracking development tasks.

William - worked on configuring MondoDB

Davey - worked on configuring MongoDB instance to our Meteor backend

11/9

The team today talked about when and who should move completed stories to the Done column. As a team, we agreed that each assignee should be the one to do that.

Diah - Since our last meeting, I tested the connection to MongoDB. I plan to confirm with other members of the team about our stories to make sure we’re not duplicating any work. Then, I plan to continue to work on my story. I had a blocker about cloning the repo and this blocker was addressed during the daily scrum today.

Remi - Got confirmation of database access - completing story for database configuration. Started researching OCR for next sprint.

Rick - confirmed DB access, reviewed Davey’s PRs, got set up with project, updated README with HW prompts, replaced sample code with receipt upload code

William - Got node, meteor, and webstorm installed. Repository cloned into git. Trying to run project

Davey - Implemented user authentication and got the code reviewed/merged.

What will you do next?

11/6

Diah - will create a simple picture upload page

Remi - will work on the functionality to extract data from receipts

Rick - will work on writing the backend functionality for uploading images

William - will work on implementing the data table for displaying picture upload information

Davey - will work on implementing user authentication

11/9

Diah - will work on ui for receipt upload

Remi - will work on functionality to extract data from receipts

Rick - complete receipt upload backend functionality, keep adding to README

William - will work on implementing the data table for displaying picture upload information

Davey - User auth is now implemented and seems to be working fine. We may want to write our own UI for the forms after we develop the app’s final UI presentation.

Impediments

We did not see any impediments that would keep us from meeting the Sprint Goal. We did not develop an impediment removal plan since we did not log any impediments.

Activity

Evidence of us updating our task board

activity.png activity2.png

Mob or Paired Programming

Diah and I paired to finish up the UI portion of a story that I wrote the backend for. I navigated her around my code she filled in the gaps to complete the story. Below is the conversation related to the scheduling of this meeting and the code that was written as a result.

paired_programming.png

pair2.png

The entire team mobbed to troubleshoot getting the application running locally on William's computer. William was the driver while the rest of us acted as navigators.

mob.png

Sprint Review

https://miro.com/app/board/o9J_kg1b1Ck=/?moveToWidget=3074457351603556576&cot=14

Our stakeholder Tressa Jamil attended as evidenced by the Zoom participant list. She wanted a few features for the next sprint:

  1. Centralized place to view all receipts

  2. Ability to categorize receipts upon uploads.

The current product backlog already covers the first request, and we added the second request as a new product backlog item.

review.png

Product Increment

A screenshot of the upload and user authentication functionalities of the app working.

increment.png

Tests

We ran server side and client side tests using meteor. Server tests are run through command line and client tests are run when the app is loaded in a browser.

client_tests.png

server_tests.png