This post is about choosing user stories to work on from a product backlog, and the lessons I learned from taking on big pieces of work.
I started at the Government Digital Service as a junior developer back in February 2014 and joined the Transition Tools software team. The team provides software and technical support for the transition of over 300 agencies and arms length bodies to GOV.UK.
Another junior developer, Tommy, has already written about his experience starting as a junior here. I wanted to write about something else that I struggled with at the start: which user stories to pick up from the product backlog.
When I joined GDS, I had no real experience of working on things picked from an organised and prioritised backlog of stories. In the beginning I thought that story points were fixed as a measure of what I was achieving and an idea of how long the task would take. I’d found myself focusing on the smaller, quicker, comparatively more straight-forward tasks and after a while I felt like I wasn’t achieving my full potential. I wanted a sense of achievement from tackling a big, relatively unknown thing.
Rails 4
To that end, back in July I took on a large user story in my team’s backlog: upgrading the Transition Tool to Rails 4, the latest version of Rails. This was in order for the app to stay up-to-date with the latest security patches and features. Over the course of completing this piece of work, I learned not only about the technical aspects of Rails 4, but how to approach and break down large stories.
The value of pre-reading release notes
One thing I learned in particular from this upgrade was the value of pre-reading release notes. Upgrading straight to Rails 4 without really preparing myself for what lay ahead—a whole host of deprecation warnings in the first instance—in hindsight wasn't such a good idea, but it did improve my debugging skills.
I ended up fixing the problems one-by-one in atomic, fairly well described commits, which was useful for eventual reviewers and those who paired on this story towards its end.
In trying to get over the first hurdle of silencing all the deprecation warnings and gem version dependency conflicts, I decided to upgrade every gem. This included RSpec, from version 2 to version 3. Version 3 of Rspec deprecates `its` without an extra gem to add it back, so that added an extra layer of complexity. According to the story’s acceptance criteria, the task was to upgrade Rails, not its testing framework, so I abandoned this extra work.
The value of pairing
Working on this upgrade made me appreciate the value and importance of pair programming. Before joining GDS I had very little formal experience of pairing, and so I found it quite exposing. I felt like I was asking stupid questions and would be looked down upon.
I was still fairly new to Rails, especially the specifics of the Transition Tool, so pairing with members of my team who had in-depth knowledge of the app was daunting but invaluable on this task.
Pairing on the upgrade forced me to confront my fear of pairing. I realised that I wasn't being judged for not knowing everything but helped. When pairing works, it’s not about one person ‘telling’ the other, but about collaborating to find solutions. Near the end, I began to enjoy the collaboration and fully embrace the learning opportunity rather than panicking.
The final hurdle
Doing the work took longer than a sprint (two weeks in our team). Towards the end I was just saying "Rails 4 yesterday, Rails 4 today" at stand-up and felt slightly guilty about it taking so long. My team’s product and delivery managers were instrumental in calming me down. They reiterated that progress isn’t just about how quickly you do something, but about the quality of what you do. Given the size and complexity of this piece of work, I relied on my team to calm me down in my times of woe.
Taking on this piece of work vastly increased my confidence, which is what I had hoped for. It did indeed give me a huge sense of achievement and everyone was happy with the end result. In tackling future stories, I will be sure to recognise the importance of both reading and writing documentation for others to rely on, and try to remember that it’s always OK to seek assistance.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
You can follow Issy on Twitter, sign up now for email updates from this blog or subscribe to the feed.
1 comment
Comment by Jorge Costa posted on
'the 80/20 rule rules'
in my view that is the correct way of choosing which story to do next. And the same rule applies to the tasks within a story.
20% of the tasks from one particular story are likely to provide 80% of the value of the backlog at that particular moment.
its one of those zen sayings, 'be lean while munching on full fat custard doughnuts'
no clue if it has been said before, I'll have the patent if I got there first