I am Scrum Master for my project that I have been working on. I am responsible for merging my team’s code (pull requests) into the Master Branch of github, and facilitating daily stand-ups to ensure that everyone is on the same page. The timing was perfect, since I reviewed Scrum’s methodology in our comparison of Waterfall and Agile Methodologies in my Software Requirements class at UMUC last week. Inspired by these events, in this post I will summarize how we adopted the scrum methodolgy when I was a student of Hack Reactor, and make comparisons to how my team implemented scrum in the project.

Scrum Methodology

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Although there may be more roles, a Scrum project defines three core roles that are vital to the success of the project: the product owner, who represents the voice of the customer and ensures that the team delivers value to the business, the development team, usually 5 to 7 developers, who actually produce the software, and a Scrum Master, who keeps the team on track and ensures Scrum is followed.

The picture below provides an excellent summary of the Scrum methodology. Sprints are timeboxed events where working software gets developed with the intention of producing a shippable product. They usually last 1-4 weeks, although as students, our sprint cycles were significantly less than the Scrum norm. For the majority of the program they only lasted 2 days, but in those cases, we worked from pre-existing code. In the project phase of the program, however, the sprints lasted 1-3 weeks, and with the exception of the Legacy project, our projects were created from scratch.  

Scrum Methodology (Source: Scrum methodology & its practical use at CVCE., 2004)

Activities

Scrum defines four events - the sprint planning meeting, the daily scrum, the sprint review, and the sprint retrospective. The core practice in Scrum is the use of daily 15 - 30 minute team (scrum) meetings that should be held around the same time each day. During our daily standups, my team discuss what we are each working on, any issues encountered, and what is the intended work to be done until the next meeting.

Throughout the first 6 weeks at Hack Reactor, we took a somewhat different approach. We instead had sprint reflections that were held at the end of each sprint when discussed as a cohort, what we enjoyed, and what did not work well for us during the sprint. Hack Reactor uses this information to improve its curriculum. I assume that HR conducts Sprint retrospectives after our sprint reflections. The purpose of a sprint retrospective is to make decisions for improving future sprints based on feedback from the sprint review. As a cohort, we benefited a few times from this exercise by receiving live lectures and sprints that were revamped to correct deficiencies that were reported by previous cohorts during sprint reflections.

Artifacts

The picture above highlights 2 Scrum artifacts - the product backlog and the sprint backlog. While the product backlog lists all the remaining requirements or features for the product, the sprint backlog lists all the remaining requirements for the current sprint. Although in practice our product and sprint backlogs were probably considered one and the same due to our short sprints, we were still able to see the concept of them in action.

My current team utilize a web tool called waffle to manage these artifacts. The waffle interface allows us to create a dashboard with intended features, issues, work in progress, work and pull requests that were completed, and work that was backlogged. Waffle was very useful since it “sat on top” of our github repo, to close off issues and pull requests automatically on github. At Hack Reactor, we also managed our product and sprint backlogs via “Readme” files that were provided during our 2-day sprints in the first 5 weeks. These files contained check boxes that we used to easily keep track of what was required, completed, and backlogged.

Scrum and Thesis Project

For our thesis project at Hack Reactor we had timeboxed sprints that each lasted a week, so we were given the opportunity implement the distinct elements of the Scrum Methodology allowing us to gain a better understanding of it.