When I started my internship at FreeAgent, I had no idea what to expect. I read previous blog posts and saw that interns get up to a wide range of things! I spent my first weeks here doing onboarding tasks and fixing small bugs. Once I’d started to get familiar with the codebase and the way FreeAgent works, it was time to start my project. 😮

My team manages Sudo, FreeAgent’s admin system where we can manage the accountancy practices and companies who use our app. One of Sudo’s most important pages, used by our support and sales teams to see information about accountancy practices, was in a state of disarray. A lot of information was squashed into a single page, making it difficult for our staff to use. My task was simple: redesign the page to make life easier for our incredible staff!

But where was I going to start? I hadn’t used this page myself, so I had no idea who used it and why. So I thought I’d start by talking to the people who use it most. 

Interviews

Firstly, I had to figure out who in the company actually used this page. My team advised me to search the logs: this required me learning where our logs are stored and how I can query them, but I got there eventually! I found that the actions on the page were mainly being performed by members of a few specific teams, so I messaged those teams to arrange interviews.

I started each of my interviews by asking the person to talk through how they used the page. Not only did this help me with identifying requirements, but it also gave me a glimpse into the workings of different teams within FreeAgent. I then asked what features on the existing page they used the most and least, and if they had any suggestions for improvements. Everyone I interviewed was really cooperative and brought lots of suggestions! Sure, it was a little nerve-wracking talking to lots of new people, but my buddy was there to support me and helped provide context on anything that I didn’t understand. After five interviews, I wrote up my findings. 📝

Spec

Next up was the tech spec. A technical specification document is where you lay out your motivations and plans for the project – Brad wrote a great post on the topic last year. Luckily, my team had done a similar page redesign the previous year, so I was able to take some inspiration from their spec. I had to answer the following questions:

• Why am I doing this project?
• Why are my main goals?
• What have I discovered from my research?
• How am I implementing the project?
• What could go wrong?
• What questions do I still have to answer?
• How will I know if the project has been successful?

At this early stage, I couldn’t fill out all the details. I didn’t know exactly the structure of my new page, but I had a rough idea – the finer details would resolve themselves during implementation.

Making a plan with Trello

Trello is a Kanban board tool that we use a lot here at FreeAgent. Kanban is a popular method used in Lean software development that uses lists to visualise and manage work. It’s a great way to organise our work as a team – hence why we use it so heavily – but it was also helpful for tracking the progress of my solo project. I reflected on all of the features I wanted to implement in my project and split them into cards. I assigned an urgency rating to each card, based on what I’d heard in my interviews – features that would help everyone, or would really significantly help one team were marked as most urgent. I also assigned a complexity score via a story scoring meeting – I’ll get to that in the next section. 😉

In my ‘Up Next’ list, I sorted the cards by prioritising ones with higher urgency and lower complexity. There were also a few requested features that I wanted to work on, but I knew that I had limited time, so I created a ‘Larger Changes, If Possible’ column for these. If these are left over once I’ve finished my project, I’ll add them to my team’s Trello board so someone will get round to them – teamwork makes the dream work! 🚀

Overall, this tool was a game-changer – I’m definitely going to use Trello to organise my work once I’m back in uni!

Story scoring

While I was putting together my Trello board, I was also writing user stories. Each user story is a description of how an end user would use our new feature, along with a list of acceptance criteria. After I’d written these, I got my team together for a story scoring meeting. Story scoring is a technique used in Agile to estimate the complexity of user stories, which helps us with planning and time allocation. As the meeting host, I explained each story I’d written and answered any questions the rest of the team had. Then we all scored them based on how long we think they’re going to take.

Now, here’s the interesting part: we use a Fibonacci scale for scoring (1, 2, 3, 5, 8, 13, etc). You might be wondering why Fibonacci: I was too! I had a quick Google and found an interesting article that explains how using the Fibonacci sequence allows us to better perceive the differences between different scores. Each number in the sequence is roughly 60% larger than the previous one, so the jump from 5 to 8 feels like it carries the same weight as the jump from 8 to 13. Pretty cool, right? 

When the time comes to reveal our scores, we play ‘planning poker’. Everybody decides on their scores separately, and then we all reveal them at once. This avoids the team members influencing each other’s decisions. Then comes the most useful part, where everyone discusses why they gave the score they did. My team members all have much more experience than I do, so hearing their opinions is incredibly valuable. There were always points brought up that I hadn’t considered at all – sometimes I would assume a story would be easy, but then somebody would raise a point that complicated everything! On the other hand, I might rate a story highly because I’m clueless about how to tackle it, and somebody else would tell me that it’s already implemented elsewhere in the app. It’s all about getting everyone’s perspective and combining knowledge to decide on the best score. ✊

Continuous feedback

After I had scored my stories and set out my plan, I was ready to dive into the code! But of course, this didn’t mean that the details of the project were set in stone. The last thing I wanted to happen was to work on the code for months, finally release it, and then find out that I’d made the page worse for my users. 😟

To avoid this, I decided to keep in contact with the people I interviewed and seek their feedback while I was making changes. The logistics of this were more complicated than I thought: I didn’t want to deploy a half-finished project to everybody, but I wanted a few people to be able to see the changes I was making. Luckily, we have these nifty things called feature switches! This means that my new version of the page was hidden behind a switch, and I could choose who I wanted to turn it on for. Everyone agreed to test out the new page, so I turned the switch on for them and can now use their feedback to improve my project.

So, that’s where I am now! I have a few weeks left of my project to work on making the more difficult changes, and to make this page the best it can be. I’ve learned so much throughout the course of this project – it’s been a great summer of learning and growth surrounded by the best people. 👫👭👬