FoodPrint: Discussing the Development Process
This is part two of a three-part series. It was written by Faith Chikwekwe and Javier Mendoza. Click here to read part one.
As we began development on FoodPrint, a carbon tracking app for your diet, we wanted to keep the user at the forefront of our minds. In order to do so, we needed an iterative, agile process that encourages frequent user testing and allows for changes to the product. Based on our knowledge from our Software Product Development course, we knew a sprint-style workflow along with pair programming sessions would help us meet this goal.
How to Plan a Sprint
In order to stay on the same page as a team, planning is very important. For an agile work flow where you make multiple iterations of the product, sprints can be helpful. In our case, sprints are two-week work sessions that can provide a sense of urgency with getting parts of the project done. Well planned sprints can provide a way to set goals, define those goals and make progress towards those goals in a timely way. This can also provide regular times to check in as a team and decide if changes to the design direction are necessary.
When working with a client or targeting a user base, this agile methodology can be an essential check-in point to make sure that the user’s needs are being put first. In a waterfall methodology, a team has to build out a large portion of the project before users can test it and see if its design is intuitive. This can lead to significant delays and financial losses if the design is prohibitive to the user decides and does not actually provide the features and services that they desire. This is why we decided that agile development would work better for our project.
Sprint #1 — Planning and User Testing
For our project, we worked in three, two-week sprints. Javier focused on front-end work like templating and designing the user interface. Faith focused on back-end activities such as routing, authentication and deployment. Our first sprint involved wireframing, user story development and initial user testing. We began by making a paper wireframe to capture the essential features required for a minimum viable product. Then, we used Whimsical to make a digital version of that wireframe. Around this time, we also wrote out a few user stories describing the user that we would like to capture and what we hope their experience in discovering and using FoodPrint would be. We did some initial user tests on our wireframe. For our first retrospective, we iterated on our initial design based on changes suggested by users. We continued to adjust the user interface design into the second sprint.
Sprint # 2 — Starting to Code and Pair Programming
This next sprint was to form the initial programming backbone for our product. During this phase, we created a to-do list outlining the tasks that we wanted to finish for our MVP. We also decided on our stack using Node, Express, MongoDB, Handlebars and Bootstrap. After pre-planning, we took a user-centered approach by starting with some essential templates.
We used pair programming sessions to stay on the same page. This involved both of us sitting at one computer while one person types and the other makes suggestions. You switch back and forth every 10 to 15 minutes whenever necessary. Pair programming is important because it helps provide both team members with a sense of ownership over their code. It also gives one a chance to identify knowledge gaps and glean information from one another.
We then began writing models and routes to serve up our templates and CRUD resources. At the end of this template, we went over the things we successfully finished and noted any bugs the we had in the back-end of our site. We also updated our to do list and added new items based on changes to our design choices.
Sprint #3 — Finishing our MVP
Our last sprint presented the greatest challenges. In this sprint, we had to finish up with our CRUD routes, add authentication to the site and deploy it to Heroku. We also wanted to do another round of user testing during the course of this sprint. We ran into many bugs during this step, especially with figuring out how to CRUD user profiles and authenticate them. Since, we planned the steps that we needed to take, we were able to write out pseudocode for these parts of the project and seek support from peers outside of the team to get this done. However, in our retrospective we realized that we were going to have trouble deploying this project to Heroku because it was so different from previous projects that we had worked on. Once again, with support from other peers, we were able to reconfigure our Heroku settings and get our project live.
Our app is still a work in progress. We hope to run another sprint through the end of December to improve the authentication and the UI design. To see the current version of FoodPrint, click here. Stay tuned for part three coming soon!
If you are interested in learning more about the idea behind this app, click here to read part one.
