By Nathan Donaldson
This post shares what I’ve learned in my first Sprint using the Scrum methodology.
As an intern here at Boost I have had the privilege of working with a group of experienced and friendly developers. I have been here two weeks now and already feel settled in completely. One of the great things about working for Boost is that everybody is very approachable when you need to ask for help or when you need things to be elaborated. This has made the transition from university to industry easier than I initially expected.
Here at Boost we use the Agile software development methodology known as Scrum. So every day I have a stand up meeting with my scrum master (Jacob Creech) and product owner (Nathan Donaldson) where I go over what I have done, what I will be working on today, and discuss problems that I need to get out of my way. So far at Boost I have been working on bug fixes for our online usability testing tool IntuitionHQ, which is built in Ruby on Rails. Working in this way has helped me get my head around the large code base that I will gradually move towards developing features for.
Using Scrum means that I’m working in ‘sprints’, or two-week long development periods. Each bug in IntuitionHQ is written up as a user story. At the start of my first sprint I took part in a sprint planning meeting which included sizing the stories (assigning them points between 1 and 8 to indicate their complexity/the effort required to fix them) and then breaking the stories down into tasks. I had to indicate how many of the stories I could commit to in the two-week sprint, and how confident I was that I could complete them in that time frame.
As an intern I was not really sure how much I could complete, being new to Rails and working in the industry in general. But one of the cool things about Scrum is that at the end of each sprint you have a sprint retrospective. This is a chance to talk about how the sprint went, and what can be done to improve things. If I don’t complete all my stories in the first sprint, the next sprint will be adapted to deal with this, and so on and so forth. So in the case that I didn’t complete all my stories it will be known for the next sprint to take on less stories in relation to their size. Overall, this is about figuring out your ‘velocity’ – how many story points you can get done in a sprint.
For my first sprint I initially committed to seven stories. I ended up completing the stories early and brought in two more stories from the backlog. One of the fun things I have found about fixing bugs is it really stimulates the mind’s problem solving abilities. I developed most of my problem solving abilities while doing my Software Engineering degree at Victoria University. Although university is a great learning environment I have found that learning in a working environment has more merits. This is because you are working with a group of people towards a common goal so they are more likely to help you out and I find that social learning is the best way to learn. This differs from university as everybody in your papers are competing to get higher grades than you so they generally don’t feed you all the facts.
One of the cool things about coming out of university into a working environment is that once you get home from work it’s your time, not stressing-about-assignments time. I believe that the less stress you have weighing on your mind the more productive you can be. Not being stressed out has helped me to be more productive working here at Boost and has got me highly motivated and keen for my next sprint.
To sum up my experiences so far I would say that working here has been awesome!
